Re: [zzdev] d.n

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

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

And their meaning is allowed to depend on context. That is important to
realize, as othrwise we end up with SQL, with different stuff in different
tables.

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

Which is exactly what *ALL* dimensions do.

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

I'm not certain whether that would really clarify anything: if we *do*
want to change that name later, then we can do a global search&replace,
no? Having the samething be called d.2 *and* d.next would be confusing and
would make the code even less understandable than it is today.

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

Before you change the code, have along talk about this with Ted. I think
that will help you see the light ;)

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

The problem with this thinking is that you think that for a given cell,
there is a uniquely defined "next" cell. Next *WHAT*? There could be the
next sibling, there could be the next person in the same room, there could
be the next person on the same level of a hierarchy. 

If you abstract the relation too high, then what will happen i that you
start needing clones for *anything* that uses a cell for more than one
purpose. That loses the connectivity and easy visualizations just as
efficiently as having too many dimensions does - nay, *more* efficiently:
you need to know which clone is on which list. 

Again, I think that this discussion is way premature: once we have 5-10
working, interoperable, reasonably complex applitudes and experience with
them, *THEN* we can start thinking of how to make them work well. Until
that time, I think it's possibly *BETTER* to live in an unclean world: at
least we won't be constraining ourselves with rules that have not
been created with practical experience.

So please, before you abstract show me actual code, a number of
applitudes, that would all benefit from it. Abstract abstractions have a
tendency to turn into all-eating monsters, I'm afraid - I do have some
experience in overabstracting things. 

> AJ pointed out that d.n are not descriptive. 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.

Yes, meaning by *context*. What's wrong with that? If you want absolute
meaning, then SQL is the system: there at least a relation always means
the same thing. But that's not the point of ZZ. Programming and using SQL
is for many things more difficult than ZZ.

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

??? The computer NEVER knows the meaning of anything. It does what it's
told to do. ZZ is something that people didn't realize it could be told to
do before Ted. As long as we can tell it what to do, it doesn't need to
bother understanding.

I must tell you that I have had similar suspicions about ZZ sometimes but
it's gotten clearer with time: ZZ is not a usual system. It's very
different from anything and getting used to the "feel", which is halfway
between practical and abstract (you'd prefer the abstract, I assume),
takes time. Don't approach it as a computer scientist; think about
different, complex bodies of information, media and so on.

	Tuomas