Changes between Version 1 and Version 2 of CollectionClassFramework


Ignore:
Timestamp:
Jan 28, 2006 1:35:45 PM (10 years ago)
Author:
jpbernardy
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CollectionClassFramework

    v1 v2  
    1 test
     1= Class Framework for Collections : Draf =
     2
     3This page describes a proposal for a class framework for collection types. Related ticket: #666
     4
     5== Goals and Non-Goals ==
     6
     7  * Focus on practical usage. No design in the abstract; what's proposed here shall be usable, and used.
     8  * Reduce the amount of explicit module-qualification that is currently required for collection types usage.
     9  * Allow algorithms to be parameterized over collection types.
     10
     11  * No attempt to fit updatable/state-monad-based collections.
     12    It looked like a bad idea to mix both updatable/non-updatable collections in a single classes framework.
     13  * No attempt to fit 100% of the existing functions into classes.
     14    Some of them are just best left in the modules to be accessed qualified.
     15
     16== Working hypotheses ==
     17
     18 * The classes are "implementation-based" (in opposition to the Edison idea).
     19   1. It seemed like a bad idea to do the same thing as something that already existed.
     20   2. Collections are about performance anyway (otherwise everyone would use standard linked-lists).
     21   3. The type give information about the programmer's expected behaviour of the collection.
     22 * 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.
     23 * 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.)
     24 * A single module is currently proposed, for ease of testing. The final version should of course be properly spilt into modules.
     25 * Most names of classes are only tentative and should be all reconsidered. Good ideas welcome.
     26
     27
     28== TODO ==
     29
     30 * Quite some functions are missing, they are ommited for the sake of brievety,
     31   until a consensus is reached on the main issues.
     32   Most of the time they should be trival to add though (eg. partition)
     33 * write instances for the new Seq type, following List.[]
     34 * See how Foldable/Travesable/Applicable fit this scheme.