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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

> > 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.

Oh, the directions will always be so that the negend is the "different"
cell, the most important cell. So those will be reversed from that spec.
 
> 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.

Exactly. I think that's a fair tradeoff. AJ?

> 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.)

I'd think d.cursor-cargo, d.cursor-list and d.cursor

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

Absolutely.

> 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.)

Totally agreed. Except that we may have both; we'll probably end up doing
runtime profiling of operations and choosing data structures eventually.

After we bootstrap.

I'm becoming more and more anxious about that: AJ, do you think we could
make bootstrap in December?

> > 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.)

Yes.

> > 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?

I wasn't but it would have been better if I was, i.e. using the
cursor-cargo cell is better.

	Tuomas