Re: [zzdev] d.n

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuukka Hastrup wrote:
> Dimensions define relations. If we have meaningful data structured, the
> relations and thus dimensions have meaning(s). 

Not necessarily. The same dimension can easily have different meanings
in different places; the authority to decide this is the user.

> One extremely common case is having data pieces listed. We have lots of
> data listed in the system structure and we'll have more. So we'll need
> to represent this meaning - being in the same list with something else.
> 
> At the moment it's "d.2". It's just a name, I hope. Can I go and define
> d.next = "d.2" in the code, please? Like I've defined "d.clone" to
> represent clones, and d.masterdim and such.

No, no, no. (In my humbly opinion, of course...) A VERY, VERY important
feature of ZZ is that one cell can be in SEVERAL LISTS ON SEVERAL
DIMENSIONS at the same time. Making one dimension the only enumenration
dimension would completely obstruct this.

That listed pieces is such an extremely common thing is an extremely
good reason not to overcrowd a single dimension with holding all of
them.

> The code needs this. IMHO it can't be d.2 forever. Until we find the
> real and correct abstraction, couldn't it be a variable?

I claim that the code does not need it.

On several occassions, we want to make a piece of code see a ZZ subspace
as a list. There is a custom to use ranks for this purpose. Not always;
for inheritance, we treat cascades as lists, for example. But generally,
when you design an interface taking a list as an argument, this
interface will take a cell and a dimension (and in the future maybe a
direction; we currently don't support this kind of thing, but the
earlier Perl prototype did, and I think it was a good thing). From the
cell, you go along the dimension (poswards currently), until you either
reach the last cell on that rank, or the cell you started from (the
former you include, the latter you don't).

And do it like this: Do NOT only take a cell, but also AT LEAST a
dimension, if not a direction. (There are exceptions, though.)

An example for this are the views (which differ in that they take
multiple dimensions). It would be pretty stupid if there was a
hard-coded alias to the X, Y and Z dimensions to be used by all the
views all the time, wouldn't it? And like we want to be able to rotate
views, we want to tell other tools the dimensions they should use.

There is no need for a special dimension being designated for sequences.
d.2 may be the COMMON one to do this, but every other dimension is just
as valid. One of the great things in ZZ is that stuff can "embrace" a
new meaning by being connected along new dimensions.

If you get *no* dimension, it may be safe to assume you should look
along d.2.

> It might be I trust myself too much. (Who am I to say anything, I
> haven't even had a chance to read "Literary Machines".)

*g* :)

> But it went
> like this: When I understood ZZ structure, I thought it's great. But
> d.n will clash, won't they? In structure, and in code. Let's make
> dozens of dimensions. Then we lost the clean visualization.
> 
> Now I see a possible answer: we can define the three casual dimensions
> to represent the general relations, like d.next. We can do this at code
> or in space: make it a variable and it's there for the code to use;
> Call it "d.next" and everyone will know what it means and how to read
> it and how to generate sequences without implicit one-to-many realtions.
> 
> AJ pointed out that d.n are not descriptive.

I think d.n *are* descriptive. They say: I'm the two and sometimes
threedimensional space you're familiar with from other computer
programs. You can use me for virtually anything, but if I get
overcrowded, you can rotate to other dimensions.

That's the way *I* get them.

> Tuomas said they're easy to
> remember. What's there to remember anyway? A name for a dimension that
> defines an undefined relation. Or multiple simultaneous definitions.
> Think multiplexing: you define meaning by place. "Unix is wrong because
> it multiplexes (data in files)," they say. If you don't agree, we've
> found a thing to discuss.

Who says that? I'd say the common idea around here is that Unix is wrong
because it requires structuring data into arbitrary hierarchical files
and directories, and treats a file as a structure which is quite hard to
interpret for most usages: a stream of characters. Defining meaning by
place doesn't seem to be an issue to me.

Let's start the discussion! :)

> And I thought we didn't love AI? That's AI, trying to guess what's the
> meaning for "d.1" today.

You don't need to guess it. Your code is told it, and if not, it darn
well shouldn't worry about d.1.

- Benja
(All IMHO's in this mail are IMHO's of their respective owners.)