Library proposal: add a Location interface for element-wise operations on Data.Map (#4887)

[Henning Thielemann]

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.