globals (was: parsing)

[Jecel Assumpcao Jr]

On Friday 07 March 2003 22:07, Brian T Rice wrote:
> > [...] Bootstrapping is specially interesting when the
> > language can't work at all without a set of tool (implemented in
> > that language!).
>
> That's interesting, particularly if the language were the only one
> capable of expressing the tools.

That would be nasty! But fortunately Self and Smalltalk are close enough 
to what I am building so I can do the tools in them.

> > [no globals in the language - only in the editor]
>
> Taking a page from the E playbook, I'd call this a "principle of
> least interaction", which probably encompasses their "principle of
> least authority". Perhaps my wording is not the best. Can you think
> of a better way to express this? It does fit with the HLL security
> model in Tunes: http://tunes.org/HLL/safety.html

"Principal of most encapsulation", perhaps? Every time I have let more 
information than strictly needed leak across interfaces it has come 
back to haunt me later.

> I find this really interesting, and we have been doing a bit of this
> in Slate, in that the namespaces are separated out quite a bit, but
> there's so much delegation between them into the lobby that it
> doesn't matter. We're planning on providing the ability to enter new
> Namespaces as persistent contexts, but for now this suffices.

I find that doing this in Self:

     ( | parent* = traits oddball.
         foo: bar = ( | temp |
                             temp: set copyRemoveAll.
                             ....

is just a rehash of how things used to be in Smalltalk. I now prefer to 
do this instead (when possible):

    ( | foo: bar = ( | temp <- set copyRemoveAll |
                            temp: temp copyRemoveAll.
                           ....

where that last line ("temp: temp...") is only needed if "foo:" is 
supposed to be reentrant. Here the object has no parent (no need for 
class-like objects everywhere) and doesn't indirectly inherit from 
lobby and globals. The object doesn't even know anything about set, 
only its foo: method does.

Like I wrote in a previous email, this doesn't work if you change the 
set object by creating a new one and then associating it with the old 
name (as Smalltalk does). You have to edit it in place keeping all old 
references (like the one in the method prototype object) intact.

> I'm curious as to how this editor works in the way of semantics.
> Basically, what scheme of objects have you arranged to make this
> work, and what are your comments on what you chose?
>
> I ask because Slate and Tunes would be interested in automated source
> generation and so there'd have to be some reflective level to do
> this. Now it seems obvious that this would be in a tool, but there
> has to be some medium-independent logic to the tool.

My current work is very much constrained by the 16 bit hardware, so I 
try to avoid having "useless" objects resulting in a design that I 
would not recommend to others. For example: methods are not objects in 
my system. Objects which are cloned from each other share a map (like 
in Sun Self) and this map holds the code for all the methods plus a 
string that is the combined source for all local methods. This string 
holds a compressed syntax tree rather than the editable text.

The editor itself is just a morph in Self 4.1.6 and hasn't been 
bootstrapped yet into the 16 bit system. That will require some 
rewritting since my GUI is simple and different.

Sorry - I think I didn't answer your question at all...

> Well, there's a common denominator of expectations about pop-up
> menus, but CLIM - or more specifically, the Genera UI - do provide
> more. However, there's a certain limit to what's intuitively expected
> at this level. There's also a limit in the number and variability of
> possibilities that a user can effectively deal with.

I must admit that previous attempts at nested editors (Windows OLE, 
OpenDoc, etc) can't be considered great successes in the sense that 
they were adopted by regular users. We shall see if this is an idea 
that looks great on paper but doesn't work well in practice.

> I also recall your essay on translating Smalltalk into Portuguese;
> it's definitely an issue I try to keep in mind.

I'll think of a way (with the least work for me ;-) of having a demo in 
English. BTW, Slate eliminated two of the hardest problems I had in 
that translation project: "self" and "OrderedCollection".

-- Jecel