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

[Benja Fallenstein]

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.

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.

- If you understand zzstructure, you understand the way *all* programs 
store their data. You can go in and look at it and modify it.
- If you have a zzstructure implementation, you can edit all 
zzstructures. If you don't have the fancy views and bindings that are 
usually used for it, it's not as convenient, but still possible.

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

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

> 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. 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. 
Additionally, applying some scrunity in human-interpreted structures 
allows writing programs (views and bindings) that interpret that 
structure and do something useful with it that's not so easily done 
manually-- for example, sorting according to some criteria etc.

- Benja