FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
Here's a reply from Daan. As I see it: we could change all the operations in Data.Set/Data.Map to be right-biased, but that's a fair bit of work and might introduce new bugs. If someone wants to do this work, it needs to be done fairly quickly (i.e. in the next couple of weeks) because we plan to release GHC 6.4 with the new code, and we won't be able to make further library changes until 6.6. Any volunteers? Cheers, Simon On 17 January 2005 12:32, Daan Leijen wrote:
Simon Marlow wrote:
Daan - any comments on this? In the absence of any objections, I'm tempted to change it back.
Hi Simon,
All the operations in (the original) DData are left-biased. I made this choice since the container is always the last argument, and than it makes sense for insert that it is left-biased -- the new value overwrites the on in the container.
I believe that most operations in the original Data.Set / Data.FiniteMap are right-biased however -- except for functions like insert etc.
This is very confusing indeed! So, there are a two choices: 1) convert to the DData bias -- silently introducing bugs in old code 2) convert DData to be right-biased -- not so consistent, but at least it would be bug compatible.
The second choice is probably best, but I didn't want to do that as it seems a lot of work since it has to be done very carefully to avoid introduction of bugs. I don't really know what the community thought which choice was best -- maybe JP knows more about this?
I hope this helps, -- Daan.
ps. Before you start releaseing 6.4, can we discuss the "reloading of dynamic libraries" in ghci again? You once gave a technical answer, but just a straightforward solution would be great -- even when it is as slow as restarting ghci, it is still very convenient to have a single command for reloading.
Cheers, Simon
On 16 January 2005 12:38, Sven Panne wrote:
Simon Marlow wrote:
simonmar 2005/01/13 02:37:39 PST
Modified files: libraries/base package.conf.in libraries/base/Data FiniteMap.hs Set.hs Added files: libraries/base/Data IntMap.hs IntSet.hs Map.hs Log: Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan Leijen's DData library, with some modifications by JP Bernardy and others on the libraries@haskell.org list. Minor changes by me to remove the last references to DData, and add a DEPRECATED copy of the old Data.Set interface to the new Data.Set.
Data.FiniteMap is now DEPRECATED.
Revision Changes Path 1.11 +3 -0 fptools/libraries/base/package.conf.in 1.20 +5 -1 fptools/libraries/base/Data/FiniteMap.hs 1.8 +1096 -69 fptools/libraries/base/Data/Set.hs
I must admit that I didn't follow the data structure discussion in every detail, but I find something confusing: In Data.FiniteMap.addListToFM_C, the combining function gets the old value as the 1st argument and the new value as the 2nd one. In Data.Map.insertWithKey (and friends), this seems to be the other way round, which is undocumented and *very* confusing when trying to port things from FiniteMap to Map. Is there a deep reason for this?
Cheers, S. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Mon, Jan 17, 2005 at 04:04:29PM -0000, Simon Marlow wrote:
Here's a reply from Daan.
As I see it: we could change all the operations in Data.Set/Data.Map to be right-biased, but that's a fair bit of work and might introduce new bugs.
Data.FiniteMap had: addToFM_C f (unitFM k x) k y = unitFM k (f x y) the new Data.Map has: insertWith f k x (singleton k y) = singleton k (f x y) Given the new argument order of insertWith, it seems the treatment of f is obviously right, and one needs to remember to flip them both when porting. On the other hand fromList is the same as listToFM. I think the only problem is union :: Set a -> Set a -> Set a, which has the same name and type as before, but different semantics. But then only people who were abusing sets will suffer.
Hello,
On Mon, 17 Jan 2005 16:04:29 -0000, Simon Marlow
If someone wants to do this work, it needs to be done fairly quickly (i.e. in the next couple of weeks) because we plan to release GHC 6.4 with the new code, and we won't be able to make further library changes until 6.6. Any volunteers?
It seems strange to me that the DData library and GHC need to evolve at the same rate. Why not have a library website where interested programmers can go and download the latest version of the library? -Iavor
participants (3)
-
Iavor Diatchki -
Ross Paterson -
Simon Marlow