Data.Map, Data.IntMap documentation

[Adrian Hey]

Johannes Waldmann wrote:
> It feels strange reading "Data.Map should be replaced"
> because it had replaced Data.FiniteMap only recently.

Unfortunately AFAIK both the old Data.FiniteMap and the new Data.Map
are based on the same underlying tree structure, which seems to do a
not particularly good job of balancing rather expensively.

Also, the efficient hedge algorithm seems to be a problem (not at
all efficient in reality).

> Are we going to play this game again soon?

Well I don't see any problem as the clone is intended to be just that.
For most users it should be a case of just changing imports to use it.
There are some API changes though, lots of stuff added and other stuff
which probably should never have been in there in the first place
deprecated or removed (like the indexing operations).

> This is definitely the case for an interface (erm, type class)
> that will allow the programmer to choose between implementations.

Not sure what it is you're talking about that's "definitely the case".
Ideally we should have just one class based API for multiple
implementations of maps, which is what the collections package Map
class aims to be.

But there are a few contenders here. There are also the Edison
classes. What is currently called the GT class in the collections
package is another (it has some weird methods in the API that typical
users wouldn't need but which are needed to implement other instances
of GT).

Regards
--
Adrian Hey