Data.FiniteMap proposed addition, bug fix
Graham Klyne
gk at ninebynine.org
Mon Nov 15 05:06:39 EST 2004
At 13:32 13/11/04 +0100, Jean-Philippe Bernardy wrote:
>On Wed, 10 Nov 2004 10:42:58 +0000, Graham Klyne <gk at ninebynine.org> wrote:
>
> > 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
> > and consistency.
> >
> > 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
> > was uncertain.
>
>That is sensible, yet you should consider my point of view as maintainer. ;)
>I'd certainly welcome extension proposals, yet DData has gone through
>a stabilization process in order to include it into the standard
>hierachy. Therefore I find it unwise to make modifications to it right
>before it gets "into production".
That's fair enough. Unfortunately, it leaves me little choice for my
application than to use a forked version of the Map module (which I am now
doing). This is unfortunate for me because I'm trying to create a
stand-alone "literate Haskell" module that is easy to load and run in any
Haskell environment; i.e. minimum external dependencies other than
standard libraries.
I did spend a little time thinking about if there could be a way to provide
just enough access to the internals of Map (and friends) to allow the
functionality to be extended by another module. But I did not have any
great inspiration. (In thinking about this, I was reminded that
traditional OO languages often have a feature that allows access to
internals of data structures to derived class implementations, but not to
other code; e.g. Java's 'protected' access. I'm not sure that thought is
particularly relevant to Haskell, other than to illustrate a perceived need.)
#g
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
More information about the Libraries
mailing list