d.n

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

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

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.

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?


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.


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.

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


Thnx for reading,
Tuukka

----------------------------------------
E-Mail: Tuukka.Hastrup@xxxxxx
WWW:    http://www.iki.fi/Tuukka.Hastrup
ICQ:	#11321669