Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Fully general cell references

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> 
> On Wed, 16 Aug 2000, Antti-Juhani Kaijanaho wrote:
> 
> > On 20000816T101717+0300, Antti-Juhani Kaijanaho wrote:
> > > On 20000816T101000+0300, Antti-Juhani Kaijanaho wrote:
> > > > I have not been able to design such a structure using any bounded number
> > > > of dimensions.
> > >
> > > Actually, I just had an idea.  I'll post details when I've convinced
> > > myself that it works.
> >
> > Ok, here goes:
> [...]
> >
> > I believe this works and is reasonably efficient.  Comments?
> 
> We had a discussion here tonight with Ted (AJ was there and kind enough to
> explain the idea again), and we decided to go ahead with it. Three
> dimensions is a lot, but OTOH one of them works for cursor-cargo so it's
> just a transition from 2 to 3, and also we can optimize this behind the
> scenes.
> 
> After this, a cursor can go anywhere so we can easily show all pointing
> structures.

I don't get it. How can you cursor-cargo with A-J's system? Except, of
course, if as the first step in dereferencing you go to an ENDCELL
(tailcell in A-J's sys, but headcell may be faster in the future, so
better use this) on the reference start dim, instead of the POSITIVE
NEIGHBOUR, as A-J originally suggested.

This makes things a bit less general than A-J intended: not every cell
can be a reference start cell. Obviously, a headcell on reference start
(that is, d.cursor-cargo) cannot reference another cell, i.e. be a
reference start cell.

On the other hand, there isn't much reason for that.

Now, what should the dimensions be called? Obviously d.cursor-cargo can
retain its name. The reference continue and reference end dimensions
remain. To be compatible with current spaces, d.cursor would have to be
the continue dimension (we then could define that if the negend on
d.cursor isn't continued on d.cursor-end, that negend shall be the
accursed cell; all cursor MOVEMENTS would change stuff to the new
system). On the other hand, this doesn't make too much sense; it would
be better to call the reference continue dimension d.cursor-list and the
reference finish dimension d.cursor. d.cursor would then express a 1:1
relation, as A-J explained. (Interesting case of loops: here, they
really mean NOTHING, but they may NOT be forbitten, because then a
cursor couldn't refer to its own reference continue cell.)

This, of course, means that we need a new space version.

As I said, we should use headcells, not tailcells, because they might be
faster. (We might have a hack that stores the headcell for every rank so
it's accessible quickly, but I doubt very much we'll have that for
tailcells.)

> I expect this will be implemented transparently in ZZCursorReal.java
> eventually.

I could do that, if nobody else does it already. (And if you tell me if
I guessed your cursor-cargo mechanism right, of course.)

> On another note, I'm adding another feature there tonight for tomorrow's
> demo: we got a bit too serious on a joke when Sonera's Veikko Hara (who is
> funding us) told us he is interested in putting ZZ over existing
> databases: we were joking about doing another demo tomorrow morning since
> one of the demos was done yesterday evening and finally the joke got
> serious and here we are, coding like there's no tomorrow (no, like there
> *IS* a tomorrow that comes all too soon).
> 
> So the feature is: a cursor can refer to a ZZPath if it has no
> cursor-cargo cell and then it takes that path, starting from the cell of
> another cursor. This is used for showing a special view of a particular
> structure. I haven't added it yet but will probably do it soon.

Are you sure you aren't confusing d.cursor and d.cursor-cargo in this
last paragraph?

Hope your demo went well.
- Benja