Changes between Initial Version and Version 2 of Ticket #666


Ignore:
Timestamp:
Jan 28, 2006 12:54:19 PM (9 years ago)
Author:
jpbernardy
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #666

    • Property Keywords collections added; Collections removed
    • Property Owner set to jpbernardy
  • Ticket #666 – Description

    initial v2  
    1 >> i propose the following class hierarchy: 
    2 >> 
    3 >> Collection 
    4 >>   Sequential (lists, arrays) 
    5 >>     UpdatableSequential (updatable arrays) 
    6 >>   NonSequentional 
    7 >>     KeyVal (AVLTree, Map) 
    8 >>       UpdatableKeyVal (HashTable) 
    9 >>     KeyOnly (Set) 
    10 >>       UpdatableKeyOnly 
    11  
    12 JPB> If anything, arrays can be seen as a KeyVal map too... We don't 
    13 JPB> necessarily want a tree-like hierarchy. In any case, please post your 
    14 JPB> suggestions on the list, preferably with the corresponding source 
    15 JPB> code. The problem is not straightforward, and we certainly want to 
    16 JPB> hear a few more opinions before deciding anything. ;) 
    17  
    18 well, i am as user of libraries just wants consistency of using 
     1Well, i am as user of libraries just wants consistency of using 
    192different data structures for the same tasks. for example, i want to 
    203have one indexing operator instead of !, !! and find. so, it's my 
    214hope-list: 
    225 
    23 1) all collections are divided into 3-4 classes: arrays/lists, maps 
    24 and sets. arrays/lists have sequential indexes in some range while 
    25 maps have sparse indexes. also each class have an Updatable subclass 
    26  
    27 2) collections in one class can be collected to each other with one 
    28 (better universal) operator, such as: 
    29  
     6 1. all collections are divided into 3-4 classes: arrays/lists, maps and sets. arrays/lists have sequential indexes in some range while maps have sparse indexes. also each class have an Updatable subclass 
     7 2. collections in one class can be collected to each other with one (better universal) operator, such as: 
     8   {{{ 
    309let list = cvt array 
    3110let tree = cvt map 
    32  
    33 3) collections can be converted to/from Updatable subclass with help 
    34 of usual freeze/thaw operators 
    35  
    36 4) all operations which are currently implemented in Data.List, 
    37 Array.*, Map, Set, HashTable modules must be bound to one of these 
    38 classes, with duplicates (such as !/!!) removed. now i see the 
    39 following class hierarchy: 
    40  
     11   }}} 
     12 3. collections can be converted to/from Updatable subclass with help of usual freeze/thaw operators 
     13 4. all operations which are currently implemented in Data.List, Array.*, Map, Set, HashTable modules must be bound to one of these classes, with duplicates (such as !/!!) removed. now i see the following class hierarchy: 
     14{{{ 
    4115Collection (map, size, values) 
    4216  SetLike (union, diff) 
     
    4822      Array 
    4923      List (tail) 
    50  
    51 i give in parentheses examples of operations which are supported on 
    52 each level of hierarchy 
     24}}} 
     25i give in parentheses examples of operations which are supported on each level of hierarchy 
    5326 
    5427 
    55 this will give possibility to write datastructure-independent 
    56 algorithms and easily convert data to the data type which are best 
    57 for each part of the program, smthg like: 
    58  
     28this will give possibility to write datastructure-independent algorithms and easily convert data to the data type which are best for each part of the program, smthg like: 
     29{{{ 
    5930a :: Map Int String <- read str 
    6031algorithm1 a 
     
    6334c :: HashTable Int String <- thaw b 
    6435algorithm3 c 
     36}}}