Changes between Version 1 and Version 2 of CollectionClassFramework


Ignore:
Timestamp:
Jan 28, 2006 1:35:45 PM (9 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.