Improving containers library

[Jeremy Shaw]

Hello,

I have a somewhat related project suggestion. As far as I can tell there is
no good Set / Map like data structure which supports multiple keys.

The closest option is happstack-ixset. However, it provides no real type
safety, and I suspect it is not very efficient:

http://hackage.haskell.org/package/happstack-ixset

As an experiment I started a data-type loosely based on kd-trees and the
existing Data.Map:

http://src.seereason.com/haskell-kdmap/

This type supports two keys. You can do looks using one or both keys.
Ideally, though, you would be able to support an arbitrary number of keys,
and do queries that are more complex than a straight lookup.

The aim is to produce a type which supports many of the same operations as a
normal database table. (But with out going so far as to be exactly like a
database table).

- jeremy

On Wed, Mar 3, 2010 at 8:23 AM, Milan Straka <fox at ucw.cz> wrote:

> Hi all,
>
> I have started an internship in Cambridge and will spend 3 months on
> Haskell. One of the possible projects is improving the containers
> library. Things I am thinking about:
> - measuring the performance of existing implementations (notably Map and
>  Set) and possibly improve them (either without or with API changes),
> - adding Queue and a PriorityQueue,
> - maybe adding a generalized trie,
> - maybe adding a hashtable (more like a trie of the hashes, something in
>  the line of Ideal hash trees; and maybe a 'classic' hash modifiable in
>  the ST monad?)
>
> I would be grateful for any comments, thoughts or wishes.
>
> Milan Straka
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100304/02bb9639/attachment.html