Re: [zzdev] Re: [zzdev] More about dimensions (lists)

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi guys,
Two unrelated comments on this ---

Tuomas Lukka wrote:
> Mathematical purity is NOT the point of ZigZag. This question is directly
> about aesthetics of the system: what to abstract and what not to.

Okay, we already know that I have slightly different senses about ZZ
aesthetics and usability than Ted; but I think a more concrete statement
we'd agree on is that it's good to have some *commonly visible*
dimensions. (I remember having had an argument about d.n's with Tuomas
some time ago, for a different reason -- space interconnection -- but I
must say the usability issue seems to be more important to me now.)
These are what you see when you start to wander through the zz space (I
like that verb ;)). The fist time you look at something, you usually see
it in the common three dimensions. So we try to let it make sense in
these three dimensions -- have the other dimensions ADD meaning, and
rotating to another dimension be the act of looking at something
DIFFERENTLY -- not to look at it for the first time. See Ted's family
demo or his various ZZ explanation pages for examples; stuff like
d.contact and d.money provides ADDITIONAL information. Also see the
FloatingWorld design decision to run execution on d.xeq, not d.2, in
order not to overcrowd the common dimensions.

(Where we diverge, again, because I would have liked another
generalization of d.xeq better than his; I think the multidimensionality
of d.1/d.xeq/d.result etc. is too hard to visualize, and would have
prefered to have dummy cells on d.1 for evaluated parameters, connecting
to the vink or other evaluation structure on d.xeq -- this way, the
standard ZZ rasters would have done the whole job. Anyway.)

> > I thought the looping was there because you'd like to represent a
> > structure that has loops. Not because you didn't want to check
> > end-of-loop and loop manually. For the first purpose, the feature is
> > relevant, for the second we could've just defined an interface function
> > instead.
> 
> True, and that feature is "headcell" once they are implemented for loops.

Don't agree. The feature is "readRank," and it only needs to be debugged
to work for loops. The point here is that you can either give a
non-looping list, which is traversed from the cell given to its end, or
a looping list, which is traversed from the cell given to *the cell
before the one given*. Headcells on loops are good for other stuff, like
resetting a special-case cursor, or to jump to with a view, or, more
generally, to "jump out of something" -- e.g. to find the "parent" of
the list.

> > This dimension list example is a good example: there's a good reason to
> > have and to not to have the dimensions as a loop. We'll want these both
> > at the same time. I could make an advanced guess, though: whatever is
> > using the list will now whether it wants a loop or a rank. So it could
> > decide between getNeighbour and getLoopNeighbour. But I called this a
> > problem: this way the looping link would mean nothing at all. Bye bye
> > all mathematical beauty.
> 
> I wouldn't say it doesn't *mean* anything. I think that the cases where
> you have a logical loop but want a list are a minority (like compassraster)
> and usually in those cases, starting from the accursed cell is actually exactly
> what *should* be one, putting the "current cell" on top of (or in the most
> important position) of the list.

Yeah, think so too: and that should be the functionality of readRank.
Isn't hard to do, either.

-b.