[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] :zz: Headcells and corner lists +d.meta
- To: ted@xxxxxxxxxx
- Subject: Re: [zzdev] :zz: Headcells and corner lists +d.meta
- From: Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>
- Date: Tue, 18 Jul 2000 14:49:08 +0300 (EEST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <22.214.171.124.20000716143551.0085f900@xxxxxxxxxxxxxxxxxxx>
I hope we can settle two things: how one-to-many relations are expressed
in ZZ (both human and computer), and how computer can determine headcell
On 16 Jul, Ted Nelson wrote:
> Right now there is no way to designate a headcell on a looping rank,
> but when there is such a thing, we'll also need a toggle to show it,
> as with every other trait.
Extending the "Corner list" concept, could we define the headcell to be
negwards along another dimension, from "the blank cell"?
> ? "Corner list" is a term that combines a structure and an expected
> function. You can have that same structure for some other purpose
> and not necessarily consider it a corner list.
It's easy to say, but hard to implement. There still has to be a way to
distinguish between corner lists and anothers, so that the headcell can
be determined and visualized.
> The top cell need not be empty, but right now that's the only way
> you can conveniently rearrange the significant items on the list--
> the top one is locked in place by its sideways connection. But
> after we implement "chug", it'll be easy to rearrange the whole
> corner list, including the top element.
If the top cell needn't be empty, how can we know it's not the
You often refer to operations one does in practise. I don't know any of
these operations; I know the trivial cell operations, but how are
bigger sets handled at the moment?
Also, how can we pick some cell contents to have special meanings
(blank cell, '+', d.something etc)? As I see it, we'd have to define
some means to escape these reserved contents if someone will have
these as data. Escapes are simply ugly. On the other hand, we can always
fix one more dimension - we've done that - and assign it a special
meaning. d.meta could be nice :-) Poswards on d.meta would be the
cell's "mode" or even mime-type: data, dummy, system-only, "go negwards
along d.content to get the headcell" etc.