Re: [zzdev] Re: [zzdev] d.n

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

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

Systems like that exist already! Relational databases are just about
exactly what you're saying here. However, SQL databases lose to ZZ in
one REALLY big area: they are not even nearly as browsable. They are more
difficult to update. Their data format is more fixed.

Being able to browse the main system data in just a few dimensions is
very handy.

Actually, I'm now thinking that possibly the system dimension list needn't
be on d.2: for the dimlist cells can be cloned from there.

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

Hmm???

Depends on the list relations. It's an artistic decision that cannot
necessarily be mathematically justified.

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

They don't resolve this in at all as handy a way: it makes it much
more difficult to choose any two dimensions and browse the structure along
them. With your d.next, d.clone would always have to be included *and*
when you get to a cell you have to look at the environment to see which
list this cell happens to be on. Not good.

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

Hmm??? I say "n <dir>" - is that clumsy? I'm giving a dimension and a
direction. Do you think there should be "make a new cell on *THIS* list
(d.next rank)? No way.
  
> > 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.

That's because currenly there is only an operation to do that. I now think
that the correct solution would be to clone from d.masterdim.

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

If there are clashes, then they are resolved. A small system need not be
able to grow infinitely without *some* adjustment at some point. The point
is that it's EASY to start the small structure and then move to a new
representation once necessary.

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

So d.next is ok? d.next is the mother of all multiplexers ;)

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

And we can. d.sibling. But d.next is not really a "meaning". If anything,
d.next is worse than d.2, since it *appears* to have a meaning but when yo
look closely,it could mean anything.
 
	Tuomas