Version 7 (modified by jpbernardy, 12 years ago) (diff)


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 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, Non-Goals and Working Hypotheses

  • 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.
  • The classes are "implementation-based" (in opposition to the Edison idea).
    1. It seemed like a bad idea to do the same thing as something that already existed.
    2. Collections are (mostly) about performance anyway (otherwise everyone would use standard linked-lists).
    3. 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.


  • Quite some functions are missing, they are omitted 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)
  • write instances for the new Seq type, following List.[]
  • See how Foldable/Travesable/Applicable fit this scheme.

Attachments (1)

Download all attachments as: .zip