Data.FiniteMap proposed addition, bug fix

[Graham Klyne]

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