Re: [zzdev] d.n

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

On  9 Aug, Benjamin Fallenstein wrote:
> 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.

Yup, that's the "(s)" :-)

Whether this kind of meaning overloading is good is undecided. I'd say
it's not good.

Why have multiple meanings for one dimension when you can have more
dimensions for free! The cost is problems in visualization. I'm trying
to sell general enough relations as the solution. Dunno.

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

I didn't mean it'd be the _only_ one, but the _default_ one. When I
earlier said we should have several dimensions for different list
relations I was told it'd be bad practise, and that you're to use
clones to resolve this kind of clashes.

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

Clones resolve this. And as far as the visualization is concerned,
while you wander the structure the current list is the center rank,
other lists show on the sides.

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

I don't like to write getNeighbour("d.2", 1) in my dimension traversal
code. It doesn't say anything. Plus, when we want interaction between
different parts of the system (like the dimension list clash) we want
certain things to be consistent. The point is this: When we want to
access different lists, it's not enough to tell the code which
dimension to use when it varies between lists. The list should tell
which dimension it's running along! (d.meta helps ;-)

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

This can be clumsy: you have to give a dimension for every - even very
simple - operation. On the code it's ok, but in UI it's not. 
 
> 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.

I'm sorry, I can't see how this fits in. This is exactly a case when
only cells are given - the dimension cells - and not the dimension
that connects them: I can cycle dimensions only along d.2.

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

I wouldn't use these but as temp dimensions. You can't help clashes
when the structure grows. These "spatial" dimensions represent the
conventional world we live in, true, but what's it to do inside a
computer? Unless you want to make your ZZ space a copy of your desk and
office and then travel up and down there, being careful not to put
heavy things on top of fragile ones etc =) This begins to look like a
"metaphor".
 
[Multiple simultaneous meanings for a dimension]
>> 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? 

Some other clever rebels =) 
http://www.tunes.org/papers/WhyNewOS/

Basically, you'll spend time deciding what's the current meaning. It
applies to humans too: multiple meanings is always a place for
misunderstandings.

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

In a hierarchy, meaning is defined by place. Same for every structure.
Hierarchies are easy ones, because there can be easy ways to define the
meaning by position. In ZZ we could see the meaning for relations from
the dimensions.


Tuukka

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