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"
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries