Data.FiniteMap proposed addition, bug fix
gk at ninebynine.org
Wed Nov 10 05:42:58 EST 2004
At 23:35 09/11/04 +0100, Jean-Philippe Bernardy wrote:
>On Tue, 09 Nov 2004 15:22:53 +0000, Graham Klyne <gk at ninebynine.org> wrote:
> > At 13:06 09/11/04 +0000, Simon Marlow wrote:
> > >On 09 November 2004 12:45, Graham Klyne wrote:
> > >
> > > > I'd like to propose an addition to the FiniteMap module in the form
> > > > of a monadic version of plusFM_C. The proposed implementation is
> > > > pretty much a copy of the existing implementation within a do block.
> > >
> > >Data.FiniteMap will shortly be deprecated in favour of DData.Map (which
> > >will be renamed to Data.Map when it is imported). Perhaps you'd like to
> > >reformulate the proposal using Data.Map instead?
> > Proposed addition:
>Ok, but in order to have a consistent interface, we'll need monadic
>versions of a lot of functions: there are Set, IntMap, IntSet types,
>and intersection, difference, etc. Might be a lot of work. A solution
>may be to make standard versions a special case of the monadic ones,
>still I wonder about performance issues.
I hadn't thought about that specifically, but I did think about other
similar functions on Map values, and it raises questions of both utility
My suggestion comes from a specific and real requirement in some software
I'm writing. Because the actual type is abstract (hidden), I can't do it
externally to the module, other than by using several function calls to
extract, merge, delete and re-insert elements, which doesn't seem desirable.
In this case, I decided to push for the particular function that I knew I
wanted, and to not expend energy on other functions whose actual utility
FWIW, other candidate functions for this treatment that I see would be:
, insertWith, insertWithKey, insertLookupWithKey
Hmmm, I also note:
and wonder why these aren't done with a monadic function? It looks a bit
like a state monad operation to me.
More information about the Libraries