Re: [zzdev] d.n

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuukka Hastrup wrote:
> 
> 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)" :-)

Ah!

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

As long as we're talking about a dimension the code takes as standard if
no other is given, ok. For anything more than that, I'd say no, clones
aren't enough. You might, e.g., want to have something at the
intersection of two lists -- using two dimensions is better than
cloning. (But then, we *are* talking about standard dimensions, right?)

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

Well, yeah, on the UI level, a default dim is probably the right thing.

Anyways, what about this: Give cursors a new "stepping dimension" which
defaults to d.2 (currently, at least) -- for real cursors, this can be a
structparam hanging from the cursor cell -- and add a cursor method
step(direction), which moves the cursor one step on the stepping
dimension. Can also have a readRank equivalent.

As there'd be a central constant for said standard dimension
(ZZCursor.java), this wouldn't be a problem.

For many operations, of course, you would use virtual cursors then.

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

No, I meant: the accursed cell plus three dimensions are given to the
raster. I'm not talking about the dimension stepping here.

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

The important part is "you can use me for virtually anything," which
derives from the spreadsheet-like structure of standard dimensions.
Again, that's the meaning they have to *me*. And I certainly don't want
to use them in a non-discrete way -- which would be a more down-to-earth
equivalent of the heavy-on-fragile thing. ;)

I use them, for example, for notetaking, when I don't want to think
about the exact RELATIONS my cells have. I consider the possibility to
do this as important, by the way: I hate it if I have to think about the
structure while taking notes -- the ideas have escaped me before I took
the notes down. I like to be able to structure them *afterwards*.

(And no, I wouldn't appreciate my ZZ space looking like my desk. ;) )

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

I'll have a look at that, but it seems to be a bit long to read before
responding. ;)

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

Well, I still think the usability/aesthetics issue is the bigger one. I
fear we won't agree on this, so let's leave the decision to the powers
that are. ;)

- Benja