Hi, may I warm up an old subject? I would appreciate if at least the Map and the Set module could be added to the base package, soon! DData.Set and the current Data.Set can be merged together (as Sven Panne mentioned earlier). Data.FiniteMap and Data.Map should co-exist for a while. The current Data.FiniteMap and Data.Set have various missing functions and instances. It would make sense to add Data.Bag also (but I don't use Bags currently) (I also don't care about Seq, Queue and Int-specializations.) The last proposal was made by JP Bernardy: http://users.skynet.be/jyp/DData/doc Daan wanted to look into it. My experiments (with large maps) wrt. performance (and memory consumption with and without optimization) of both Map and FiniteMap implementations revealed differences, but no crucial ones. "FiniteMap Int a" performs better than "Map Int a", but not as good as "IntMap a", but the differences are unimportant for us. (We would need a pure HashMap with O(1) lookup while extending the Map) Christian
Hello everyone, For those who care, I've fixed a bug in "unions" for Bag and IntBag. Find the update at the usual URL. BTW, is there anything that I can do to prepare integration in the standard libraries? It has been proposed to emulate Data.Set interface, though I wonder if this is right because: 1. IIRC, there is the semantic difference of left-bias right-bias, that can be observed for types where Eq/Ord is not strutural; 2. Backward compatibility will not be achieved anyway, because identifiers will clash with those of the prelude. Cheers, JP. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
hello, i suppose we could put it under Unstable.* but i don't think that is very nice, as it really did not work out well for the monadic library. i would prefer that the library had an independent distribution, and can be easily downloaded and experimented with. -iavor JP Bernardy wrote:
Hello everyone,
For those who care, I've fixed a bug in "unions" for Bag and IntBag. Find the update at the usual URL.
BTW, is there anything that I can do to prepare integration in the standard libraries? It has been proposed to emulate Data.Set interface, though I wonder if this is right because:
1. IIRC, there is the semantic difference of left-bias right-bias, that can be observed for types where Eq/Ord is not strutural;
2. Backward compatibility will not be achieved anyway, because identifiers will clash with those of the prelude.
Cheers, JP.
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
i would prefer that the library had an independent distribution, and can be easily downloaded and experimented with.
Perhaps it would be a good candidate for the new packaging infrastructure? btw Note that distributing it independently doesn't mean that it can't live in the main cvs.haskell.org cvs repository. (The converse doesn't appear to be true: if you want it to become part of the standard distribs, it probably has to live in cvs.haskell.org just to keep it easy for the distrib builders who tend to like to be able to create branches, tag the repository when they make a release, etc.) -- Alastair Reid
participants (4)
-
Alastair Reid -
Christian Maeder -
Iavor S. Diatchki -
JP Bernardy