Re: Data.FiniteMap proposed addition, bug fix

At 13:32 13/11/04 +0100, Jean-Philippe Bernardy wrote:

On Wed, 10 Nov 2004 10:42:58 +0000, Graham Klyne 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