More about dimensions (lists)

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

Hello,
Once again I hit a problem in the current dimension usage scheme - or
in the fuzziness in it. This is about one-to-many relations, a general
enumeration dimension and corner lists. I wanted to tell you about this
instead of hacking my way through, because I see this as a proof that
we should decide how to handle one-to-many relations consistently.

It should be possible to give compass raster the dimension list it
should use. At the moment, it's not possible to use the normal lists, as
the DimLists for views and the space master dimension list are of
different format: 
* on masterlist the dimensions are enumerated along d.masterdim, on
DimLists along d.2. 

Earlier, I guessed that we should have a dimension for every
enumeration type - for cells being able to be part of different lists
at the same time. However, cloning is sufficient, as long as we want to
deal with cell contents and not with real cells. And when we're listing
cells themselves, we'll use marks - right?

Now it seems like one enumeration dimension could be enough, given the
ability to make clones. "Being after something" is a very usual and
general relation, as is its counterpart - "being before something." 


Also, both lists are of wrong format:
* master dimension list includes home cell as the head cell. It's not a
dimension!

I claim corner lists are the only right way. After all, as we reduce
one-to-many relations to multiple one-to-ones, we have two different
relations, the original intended, and the enumeration. Using headcells
is wrong, as we see on d.masterdim: d.1 is sure a dimension in the ZZ
space, but d.2 isn't a dimension in d.1!

* DimLists are circular. Then, it's about infinite number of dimensions
to be shown by compass raster.

This seems like a problem. It comes from the ZZ space axioms - the
possiblity to have loops, I mean. It makes the model clean, there's no
need for special restriction "you can't loop". But the general data
structure case is to not have loops. And every loop can be reduced to a
list. Think about the DimLists: there's a finite number of dimensions,
but infinite number of steps forward. You can want it to be infinite so
you can cycle through it forever, but you can also want to get just a
finite list containing all the dimensions.

In short: DimList cycle is just a hack to make it easier to cycle
through dimensions. Is it so with every other loop too?


Suggestion #1: we rename d.2 as d.next and give it the honour to be one
of the very special dimensions in ZZ space, implementing one-to-many
relations.

Suggestion #2: we turn every one-to-many relation - be it corner list or
not - to a corner list using d.next.

Suggestion #3: think through the loops now; could we get rid of them,
should we make special operations for them (ie. getNeighbour and
getLoopNeighbour), should we always have both a looping and a
non-looping version of lists (along d.next and d.lnext)

Suggestion that-is-the-most-relevant: think about this, tell me why I'm
wrong, and tell me what to do in compass raster :-)


Tuukka

----------------------------------------
E-Mail: Tuukka.Hastrup@xxxxxx
WWW:    http://www.iki.fi/Tuukka.Hastrup
ICQ:	#11321669