Re: [zzdev] More about dimensions (lists)

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

> >> This seems like a problem. It comes from the ZZ space axioms - the
> >> possiblity to have loops, I mean. It makes the model clean, there's no
> >> need for special restriction "you can't loop". But the general data
> >> structure case is to not have loops. And every loop can be reduced to a
> >> list. Think about the DimLists: there's a finite number of dimensions,
> >> but infinite number of steps forward. You can want it to be infinite so
> >> you can cycle through it forever, but you can also want to get just a
> >> finite list containing all the dimensions.
> > 
> > There are supposed to be headcells for looping lists. With them, reading
> > just the dimensions is going to be easy. You can also see manually whether
> > you're looping.
> 
> Here, it seems like we're destroying the loops. When a loop has
> a beginning, it also has an end. And this defines a list.

Every loop defines a list but every list doesn't define a loop.
 
> >> In short: DimList cycle is just a hack to make it easier to cycle
> >> through dimensions. Is it so with every other loop too?
> > 
> > You could also say that ZigZag is a hack to mke it easier to structure and
> > visualize information naturally. Both are equally true in a sense.
> 
> A hack? A well defined structure. I mean, does it _tell_ something,
> mean something, to have a rank that loops? Because at least as a list,
> a looping rank _means_ an infinite list. And as there is finite amount
> of dimensions, a loop is a hack.

Since when are there a finite amount of dimensions? That's news to me ;)

A rank that loops is very useful when you work on operations that move
the cursor one cell. Think about e.g. finite-state machines. If looping 
ranks are not allowed, they become much more complicated, because all loops
must go through two dimensions.

A looping rank means a looping rank - a loop of states. It also meas a *finite*
list, of the cells starting from the headcell, just as mentioned above.

> And imho we're talking about that naturalness. It's not natural to be
> consistent or exact, but we'll need it for the abstractions in our code.
> We should think over these and then implement the higher level
> abstractions ourselves, to eliminate the need to be consistent later on.
> We're building a universal data structure, a system based totalitarily
> on it, _and_ a framework. Isn't it the framework designer task to think
> over the best ways to do things and then give an implementation to these
> ways?

Yes, absolutely. This is an issue we will have to discuss with Ted once he 
arrives (we start sessons on sunday, probably).

> >> Suggestion #1: we rename d.2 as d.next and give it the honour to be one
> >> of the very special dimensions in ZZ space, implementing one-to-many
> >> relations.
> > 
> > Clones are also a one-to-many relation. Should that too be handled on
> > d.next? 
> 
> Shall I say: a good question =) Not really, we don't need to. At the
> moment clones are clones of the cell before them. For the first time,
> you clone the data cell, after that you clone just the clone cell. So
> we have these relations that "cascade" like d.next and d.clone.
> 
> But we might want to think this through, however =) These cascading
> relations are a very interesting case: the headcell really has a
> meaning - it's the first or the original or the one pointed to etc. 
> 
> Let's imagine d.clone turned into a corner list (I don't want to do
> this to d.next right now! ;-) It would be as easy as before to find the
> original cell from a clone. What would it change? You could distinguish
> between "a clone of a clone" and "another clone of the original." It
> would be more complex to create a clone: you'd have to check whether
> the clone list for this cell already existed and perhaps initialize the
> list.

The question is: do you *want* to distinguish?

> At first glimpse, it seems to me it wouldn't be worth the effort to
> make d.clone a corner list. But this could change if we are to provide
> a general interface to one-to-many relations.

A general interface like getNeighbour, getHeadcell, connect, insert? That's
a general interface to any structure and I'm notsure whether abstracting 
many-to-one from it is necessary. But this is something we'll need to talk about
in person and with Ted:.

> > In a sense, d.2 *is* the d.next you are thinking about: Ted's
> > comment about it is that it's usually used to indicate sequence.
> 
> A part yes, a part no. "Usually" is not enough. Make it 'always' and
> I'll make it a ZZSpace property like d.clone and d.masterdim, and
> provide a general interface to it. Then it could help the users to know
> it by name "d.next". I see it could be possible, because d.next is
> really important and omnipresent - it's one-to-many relations
> everywhere.

ZZ is not about "always" and "never", usually.

> As we're talking about this, we could find out if it would be possible
> to generalize d.1 and d.3 too. d.1 seems to mean pretty much "is a"
> (often a list) or "is defined by" or "is sum of these parts". d.3 is
> not used so much (maybe some other dimension could be more important),
> but it's found in meanings "inheritance" and "superclass", abstraction:
> "is-a-special-case-of".

d.1 is also used to connect first name and last name, command parameters,
may things like that.

> I feel very smart doing this (please don't _shoot_ but take me down ;-)
> I've felt there's never going to be a clean way to deal with these
> thousands of dimensions. Or dozens - our "ZZ Subgroup's" nickname is
> "d.n haters" =)

I hope you don't consider the following "shooting down".

Would I be right in thinking that you somehow feel that ZZ structure is
messy and you want to "clean it up" by imposing on it other structures
that you've learned elsewhere and think are "cleaner"? Try rereading the place
in literary machines where Ted talks about "noids" and the enforced difference
between '0' and 'O'.

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

You "d.n haters" have in common a very abstract sense of aesthetics: you
both, I would believe, like things like labda calculus and so on. This
means that you want to abstract anything and everything until it is wrapped
in a neat little package. There is nothing wrong with this: this is how
computer theory is advanced. However, it is not necessarily the right attitude
towards user-friendly systems. Languages that support lambda calculus usually
pour a HEAP of syntactical sugar on top of it - guess why. To make it usable.
Lambda calculus is a nice theoretical tool but for doing anything with it
in real life, most people will usually need more powerful tools on top.

In the same way, having sets on d.next would be much nicer *theoretically*
an in practice. On a theoretical level, I'd possibly agree.

However, when you get into practice, the picture changes. It is much
easier to do things if there are more dimensions "free" and dimensions
have meanings. Consider Ted's family tree demo. One (or two)-to-many
has a real-life significance there.The dimension describes that significance.
Having to join the children first on d.child and then on d.next would
make it far less visually appealing. 

Now, you *can* abstract it and make a view that shows *that* structure.
But what you have done then is to define a *different* metastructure
on top of ZigZag. Instead of ZigZag, you're using "SetZag", ZZ with sets.

> >> Suggestion #3: think through the loops now; could we get rid of them,
> >> should we make special operations for them (ie. getNeighbour and
> >> getLoopNeighbour), should we always have both a looping and a
> >> non-looping version of lists (along d.next and d.lnext)
> > 
> > I feel that this would be unnecessary complexity: if you are afraid of
> > loops, you should simply use LoopDetector. It's very simple and cheap. 
> > Because if your structure is any more complicated than a list, you *are*
> > going to have potential loops and removing lops from lists is not going to
> > help you any.
> 
> Two different things here:
> - be careful to avoid crashes when it's possible to run to an infinite
> loop
> - have the structure represent the meaning
> 
> LoopDetector's clever. (It could detect small loops too). But I wasn't
> talking about this technical problem. An example: in compass raster, I
> go through the DimList loop. I will get some dimensions several times,
> and I will show them several times. This is wrong. 

That's because LoopDetector is not meant for that use.

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

Actually, what I think compass raster should do is to start from the given
dimension and go downwards until it finds the loop. That way it shows 
all dimensions, with the currently active dimension on top - not at all
a bad arrangement. Or you could put it in the middle, which would be nice 
as well.

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

> >> Suggestion that-is-the-most-relevant: think about this, tell me why I'm
> >> wrong, and tell me what to do in compass raster :-)
> > 
> > Maybe change d.masterdim to d.2?
> 
> Yup, these is sure the right thing to do for the dimension list. But
> it's a more general problem. We'll get lots of corner lists. Should be
> spec this stuff and make it a supported feature? 

How is it no supported now? ;)

> P.S. Sorry. I'm trying to spare words, but it's not that easy.

You're doing much better already.

Like I said, this is something we need to discuss face-to-face as well as
with Ted. Once you spend time with him and possibly grasp his sense of 
aesthetics things may become much clearer.

	Tuomas