Names for general merge tactics in Data.Map

[Bardur Arantsson]

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?