Re: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs

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.

Sven Panne
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?
Hmmm...I have perhaps a rather shallow reason. When using a FiniteMap to collect lists of values, I think it will be more efficient to use (flip (++)), prepending instead of appending each new element. (It's a while since I looked at this, so it may not be exactly correct) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On Mon, Jan 17, 2005 at 08:38:12AM +0100, Ketil Malde wrote:
Sven Panne
writes: 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?
Hmmm...I have perhaps a rather shallow reason. When using a FiniteMap to collect lists of values, I think it will be more efficient to use (flip (++)), prepending instead of appending each new element.
If (flip (++)) is efficient for one interface, shouldn't (++) be as efficient for the other? Why not use efficient catenable sequences or a ShowS trick, like here: groupFM :: Ord a => [(a, b)] -> FiniteMap a [b] groupFM l = mapFM (\_ -> ($ [])) $ addListToFM_C (.) emptyFM [ (a, (b:)) | (a, b) <- l ] PS. If anyone asks, I am strongly against introducing such artificial differences in library interfaces. Best regards, Tomasz

Tomasz Zielonka
Hmmm...I have perhaps a rather shallow reason. When using a FiniteMap to collect lists of values, I think it will be more efficient to use (flip (++)), prepending instead of appending each new element.
If (flip (++)) is efficient for one interface, shouldn't (++) be as efficient for the other?
Yes. Sorry if that wasn't clear; my point was that the new interface saves you the 'flip' -- or alternatively, the naive user not considering these issues will likely just use (++), which may be more efficient for the new interface.
Why not use efficient catenable sequences or a ShowS trick, like here:
groupFM :: Ord a => [(a, b)] -> FiniteMap a [b] groupFM l = mapFM (\_ -> ($ [])) $ addListToFM_C (.) emptyFM [ (a, (b:)) | (a, b) <- l ]
Because it is more complex? It's a neat trick, but it does takes me a minute or two to see what's going on. Perhaps groupFM should be part of (Finite)Map? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (3)
-
Ketil Malde
-
Sven Panne
-
Tomasz Zielonka