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

[Simon Marlow]

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 at 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries