Class Framework for Collections : Draft

This page describes a proposal for a class framework for collection types. Related ticket: #666

Please give me feedback by either mailing me (jeanphilippe.bernardy at gmail.com)
or edit this page; or issue tickets (see CollectionLibraries); or any other means.
I'm mainly interested in concrete examples where the framework would fall short to meet your needs.

Goals and Non-Goals

Focus on practical usage. No design in the abstract; what's proposed here shall be usable, and used.

Reduce the amount of explicit module-qualification that is currently required for collection types usage.

Allow algorithms to be parameterized over collection types.

No attempt to fit updatable/state-monad-based collections.
It looked like a bad idea to mix both updatable/non-updatable collections in a single classes framework.

No attempt to fit 100% of the existing functions into classes.
Some of them are just best left in the modules to be accessed qualified.

Working hypotheses

The classes are "implementation-based" (in opposition to the Edison idea).

It seemed like a bad idea to do the same thing as something that already existed.

Collections are about performance anyway (otherwise everyone would use standard linked-lists).

The type give information about the programmer's expected behaviour of the collection.

This deliberaty uses many symbols already in the prelude. The intent is that the user hides whatever clashes from Prelude, however it's also possible to import this module qualified.

This uses functional dependencies. This is motivated by the fact that it gives a lot more expressive power without much inconvenience for the users. (note: We should consider porting this to Associated Types, since it's an alternative for FD in next version of Haskell.)

A single module is currently proposed, for ease of testing. The final version should of course be properly spilt into modules.

Most names of classes are only tentative and should be all reconsidered. Good ideas welcome.

TODO

Quite some functions are missing, they are ommited for the sake of brievety,
until a consensus is reached on the main issues.
Most of the time they should be trival to add though (eg. partition)