On Fri, 7 Jan 2011, Ross Paterson wrote:
This is a variant of a suggestion by apfelmus:
http://www.haskell.org/pipermail/libraries/2010-September/014510.html
To avoid proliferation of variants of element-wise operations, the idea is to split these operations into two phases mediated by a new Location type, so that users can do whatever they like between these phases. Documentation is here:
http://code.haskell.org/~ross/containers_doc/Data-Map.html#3
This adds a type and 9 functions to the interface, but makes possible monadic updates and much more. As an illustration, the file MapOps.hs attached to the ticket gives definitions of 30 of the public functions of Data.Map in terms of the new interface. At least in the case of insert, this definition is slightly faster than the current one.
This looks very very cool! Frequently I wanted a certain combination of lookup/delete/update that was not available in Data.Map, but plenty of other combinations instead. :-) Location is really a hole, where a certain element is already removed? Then I find Location as name a bit misleading. I assumed, that a location also lets me peek the particular element. If the meaning remains, how about the name Hole? Otherwise if using Location for reading an element turns out to be useful, the name should remain. (I find Apfelmus' suggestion of Focus also appropriate.) Before giving a final vote, I would like to scan my code for overly complicated accesses to Map, due to missing Location. I am currently downloading containers' darcs repository.