A single general modification function for Map and IntMap proposal

[Nikita Volkov]

>> I think consistency with the rest of the Map API is more important than ease of use with lens/nested compositions.  I agree that the current arg ordering is often inconvenient, but having some functions ordered one way and others a different way seems a very poor decision.

It's worth reminding that an important part of this proposal was to begin a deprecation process of all functions that become redundant in presence of `alterF`, and by accident it so happened that they were the only ones introducing the parameter order conflict. Deprecating them we acknowledge the fact that there's something wrong about them and that there's no need to be consistent with that.

Here's a quote from original proposal:

   2. Change the order of parameters from "lambda -> key" to "key -> lambda". 
   3. Begin the deprecation process of the following functions: insertWith, insertWithKey, insertLookupWithKey, adjust, adjustWithKey, update, updateWithKey, updateLookupWithKey, alter.

> +1 for the key -> lambda form. Even disregarding lens, compositionality is extremely important. Not to mention which, the key -> lambda form feels much more natural even on its own. You provide an "index" and get back a function that lifts element modifications to map modifications.

That's exactly what I had in mind when proposed this. I however am now conflicted about that, since I see the "lambda -> key" order to be compositional too in its own way: you provide a lambda and get a function ready to modify a map at a key in that specific way.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130620/73cd1518/attachment.htm>