I don't understand your comment about having both table indexing and insertion in the same time but not both at the same time, could you expand on that?
Ah, it was nothing wise, if one use tables he can chose whether
(1) he uses natural numbers (integers) as indexes (i.e. keys), just like list, T[1],T[2],... If such table represents some monotonous ordering (i<j =>T[i] |<| T[j]) of the values, lot of things are fast, like successor, predecessor, generation of all values respecting order |<| , decision whether value is in structure. (|<| is not Unicon operator, it is meta-symbol.) But, insertion is slow.
(2) If fast insertion is allowed, for example between T[i] and T[i+1], T[i+0.5]:=x some advantages are lost, like fast search for value in the table, search for its predecessors and successors and generation of all values respecting |<| order (at least manual says that generation of the elements of table is unpredictable.)
One have to decide between (1) and (2).
==============
However, after night of sleeping, few (not all) important advantages of lists can be easily introduced back in tables, for example
(a) for fast decision whether value is in table, "inverse table" T2 such that T2[x]:=i+0.5 can be maintained along with T.
(b-c) for fast search for predecessor and successor, and generation of all keys and values in table respecting orders < and |<| , table can be crossbred with classical linked list and instead T[i+0.5]:=x one can use
record node(pred,succ,main) T[i+0.5]:=node(i,i+1,x)
With some interface this combination can be cute data structure.
----
Kazimir Majorinc, Zagreb, Croatia
