Names for general merge tactics in Data.Map

[David Feuer]

Consider them severed. I'm most interested in getting generalMerge settled.
I can leave the question of what to do with mergeWithKey alone for a while.

On Aug 19, 2016 12:59 AM, "Bardur Arantsson" <spam at scientician.net> wrote:

On 2016-08-18 22:40, David Feuer wrote:
> I like the idea of using separate modules. What would you like them to
> be called?
>
> I am open to the idea of leaving mergeWithKey in, but I'm not yet
> convinced. Can you give an example of a realistic application of
> mergeWithKey that cannot easily be rewritten in terms of generalMerge?
> I would normally agree with you that backwards compatibility should be
> preserved. However, mergeWithKey has several very serious problems.
>
> 1. It allows the user to produce invalid maps. Unlike other functions
> that do so, it's not clear that it offers any significant efficiency
> benefit (once generalMerge is added).
>
> 2. It breaks the map abstraction. A user could invoke mergeWithKey
> with arguments that cause it to produce semantically different maps
> depending on the way the given map is balanced. For example, a user
> could pass an only1 function that deletes the median of the tree it is
> passed. I don't know how to document the appropriate restrictions
> required to preserve the abstraction.
>
> 3. It is very hard to figure out much about what mergeWithKey does by
> looking at its name and type. Indeed, I did not understand it from its
> documentation either, and had to read the source code.
>

Maybe it would be better to de-copule this into two proposals, one for
adding generalMerge (or whatever it ends up being called #bikeshed), and
one for depracting/removing mergeWithKey?


_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160819/f5ee8fff/attachment-0001.html>