Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...

[Tuomas Lukka]

On Sat, Oct 05, 2002 at 05:36:45PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >On Sat, Oct 05, 2002 at 02:34:50PM +0200, Benja Fallenstein wrote:
> > 
> >
> >>I really think paragraphs should be visible in zzstructure for 
> >>rearrangement. 
> >>   
> >>
> >
> >Ahh, that's a very different thing, actually. This means that there needs
> >to be a "structure view" in which the paragraphs show in different cells.
> >
> >This is not the same as storing paragraph tags in the structure.
> >
> 
> Ok, this is a more fundamental issue.

Definitely. Note, of course, that I'm really undecided on this issue
and therefore am playing the devil's advocate.

> In my book, zz is about what you gain when you make everybody agree on a 
> single structure that allows for rich interconnections. You get 
> consistency, and the property that absolutely everything can be 
> connected to everything else, and human explorability of all data.

The problem here is that we don't really achieve the idea
of "absolutely everything can be connected to everything else"
when we make rules for how programs are supposed to understand 
the structure. 

A program may easily delete, when editing, a cell that was the connection
to somewhere else, because it thinks (in terms of the local applitude)
that that cell is not needed any more.

> - If you understand zzstructure, you understand the way *all* programs 
> store their data. You can go in and look at it and modify it.

Yes, this is the great promise. The big question is whether this can
really be reached.

For example, anywhere you edit text, you'd need to take into account
the special two-enters keystroke and edit the structure. 

> Now, your argument is, "we can view everything in zzstructure, even if 
> it's not stored in the zzstructure itself, through spaceparts." However, 
> something that can only be viewed through a spacepart is *not* a 
> first-class member of the zzstructure. You don't see the actual data 
> used. You can only manipulate the data according to the interfaces 
> provided to you by the application programmer. You cannot see or edit 
> the data at all if you don't have the right spacepart. You cannot use 
> the primitives of zzstructure (such as clones and cursors) when editing 
> the spacepart structure (if not expressly allowed by the spacepart 
> developers). "Everything can be viewed as zzstructure" is much less 
> strong than "everything is in zzstructure."
> 
> So: My take is that "you can show everything in zzstructure" is not a 
> valid argument against "the data should be in zzstructure."

Agreed.

> >>Hm. Seriously, I don't think that "don't put data into zzstructure, it's 
> >>bad" is a sane philosophy for this project. We *have* also gotten into 
> >>trouble over not putting enough into zzstructure (e.g. cell existance).
> >>   
> >>
> >
> >I know. This is why we need to consider the alternatives carefully.
> >Some ZZ structures which are interpreted by a program seem to be 
> >surprisingly
> >fragile, and sometimes difficult to change with the general 
> >utilities.
> >
> 
> What exactly are you refering to? And why difficult to change?
> 
> Putting each character in its own cell (the vstreamdim approach) was a 
> big mistake because the optimizations intended to make it work never 
> worked correctly. But that doesn't seem to be what you're refering to. 
> What is it?

Basically, any interaction between two structure. Can we really have
a situation where different applitudes' data shares cells and have it
really work?

I'd really love it if you can convince me on this.

> >I've been lately thinking a lot about this and whether we should, instead
> >of using structure as data, emphasize the point of using the structure
> >directly by humans. Because there things aren't as fragile.
> 
> Certainly the project hasn't been emphasizing the point of using 
> structure directly enough-- there's been this bias that 'applitude' 
> means 'views and bindings that hide the structure.' But turning 180? and 
> saying that structure interpreted by programs is bad or not important is 
> just as wrong. 

I'm not saying it's bad. I'm just afraid of all the difficulties
when there are several programs using the same cells from orthogonal
points of views.

The potential interactions between the programs are very complex
and it'd be easy to get undesirable emergent behaviour (oh, because
this applitude wanted to insert a linebreak here, it split this cell,
and because of that, this other applitude didn't see that half of the
text and the xanadu link there any more etc etc etc).

This is the one part which Ted never talks about: there are all these
clever and simple things that can be done with the structure, but once
these simple things are combined, really bad complexities can emerge. 

> The idea of zzstructure is that all activities around the 
> computer take place in the same structure, allowing interconnections and 
> overlap between *everything*, human-interpreted or program-interpreted. 

Exactly. My question (which I haven't been able to formulate as clearly
earlier) is whether we can handle the ensuing complexity.

Also, note again that my true views are somewhere between what you say
and what I say here; I also hope for great things but here I present 
the fears.

        Tuomas