Re: [zzdev] Re: [zzdev] Re: [zzdev] More about dimensions (lists)

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

(I may not be answering to all your points properly here because I didn't
get enough sleep last night. Apologies).

> > Since when are there a finite amount of dimensions? That's news to me ;)
> 
> How do you plan to store, say, countably infinitely many dimensions in
> your computer?
> 
> Tuukka wasn't saying that there is an upper bound for the number
> of dimensions.  He just meant, AFAIK, that at any point there are
> finitely many nontrivial dimensions. 

We might have an automatically generated part of dimension namespace,
which could have a countably infinite number of dimensions that spring
to existence when you use them and vanish when you don't.

For example d.text-grep-<word> where word is replaced by a word, which
connects all cells with that word in them.

But this is not realistic, really; I was wrong again. I always mix those
terms for some reason.
 
> > A rank that loops is very useful when you work on operations that move
> > the cursor one cell. Think about e.g. finite-state machines. If looping 
> > ranks are not allowed, they become much more complicated, because all loops
> > must go through two dimensions.
> 
> I believe Tuukka wasn't talking about banning loops, but about
> banning loops where they don't have a meaning, ie. where they are just
> a "convenience hack" - since that convenience hack could in fact be
> done in other ways too, for example by defining the "cursor negwards"
> operation on a headcell to meaning "cursor to endcell".

Well, the question becomes: which of those is the convenience hack.
Which is less meaningful. In both, the end result of the cursor negwards
is the same cell. So it is an aesthetics question. To me, the loop makes
sense: then the dimension simply expresses a "successor" relation.

Would you draw the Z_7 modulus field as a circle or as a list?

> > A looping rank means a looping rank - a loop of states. It also meas a *finite*
> > list, of the cells starting from the headcell, just as mentioned above.
> 
> A looping list can *also* be understood as a finite representation of
> a repeating infinite list.

Usually it's not intended to do that, I'd expect. A looping list would usually
be just the successor relation in a pairwise manner.

> > The question is: do you *want* to distinguish?
> 
> And the related question is, whether the clone relation is transitive.
> Ie. if A is clone of B and B is clone of C then A is clone of C.  I feel
> that it should be.

Right. So clones would not be on d.next.

> > d.1 is also used to connect first name and last name, command parameters,
> > may things like that.
> 
> /me has some problems with using one thing for many things, but that's
> probably because /me has been brainwashed by the department :-)

And you have a different sense of aesthetics. That's perfectly fine. We'll 
need to figure out a way for people to use their favorite structures easily
so you can have it your way, I can have it mine and Ted can have it his.

> > Try rereading the place
> > in literary machines where Ted talks about "noids" and the enforced difference
> > between '0' and 'O'.
> 
> Is "literary machines" available somewhere, in a readable format?

Not electronically - I can lend you my copy.

> I don't know about Tuukka, but my sense of aesthetics says that things
> should have a simple but powerful foundation (such as lambda calculus
> for a programming language) which has powerful abstraction mechanisms
> that allows you to build anything you like on top of it.  I don't care
> if you define even a large standard library (such as Common Lisp does),
> but I want the core to be small.

In a sense, then, wouldn't the proposal of explicificating many-to-one
relations go agains this sense, too: the ZZ structure is a simple and
powerful foundation; does it really *need* the standardized many-to-one 
thing?

On the whole, something like that *may* happen some day but more likely
with the dimension left blank for the applitude to fill in.

But that day will come only after we have had sufficient experience with
a sufficient number of applitudes in order to start bstracting out what is
really needed. Note how long it took programming languages to come up with
any reasonable abstractions - we are just starting on a new system. o
at the moment, IHO it's more important to do a lot of hacky experiments
and THEN think about standards - not *before* they are needed.

> > In the same way, having sets on d.next would be much nicer *theoretically*
> > an in practice. On a theoretical level, I'd possibly agree.
> > 
> > However, when you get into practice, the picture changes. It is much
> > easier to do things if there are more dimensions "free" and dimensions
> > have meanings.
> 
> How do d.1, d.2 and d.3 have any meaning at all?  Why not call them d.foo,
> d.bar and d.baz?  They'd be about as descriptive.

But longer and harder to remember for non-CSers. 1-2-3 is pretty easy
to live with.

> And we have a countably infinite supply of dimensions.  How can we ever
> run out of them?

Oops, I was unclear. By "free" I was referring to the three visible
dimensions: the more of them somehing uses, the less easy navigation becomes,
like Benjamin was saying.

	Tuomas