globals (was: parsing)

[Brian T Rice]

On Wed, 12 Mar 2003, Jecel Assumpcao Jr wrote:

> On Friday 07 March 2003 22:07, Brian T Rice wrote:
> > > [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.

Okay, this is good.

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

Slate is generally using Smalltalk grammar and block closure semantics, so
the former is required.  Anyway, yes that's a good example. Generally, the
thing I've been doing in this regard is to reduce all cross-package
(named) references to specific points in the code, such as initializing a
prototype's slot, and to just have each re-initialization or copy or other
method simply access the types of the arguments' attributes for creating
new kinds of those objects, which allows for some parametrization. i.e.
the compiler could substitute a ByteArray for an Array somewhere and the
libraries won't "undo" this change unless it must (say, when calling
collect:).

> 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 have been considering making a package object that represents a
"configuration" of objects and methods with requirements and provisions.
This kind of constraint definitely affects that.

Certainly Slate does not fully support in-place editing; a good example is
that we can't remove methods or perform other such queries. Anyway this
will go away once bootstrapped.

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

That's fine. It's still interesting.

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

I'm glad we could help. I suppose your essay was in the back of both Lee's
and my mind when we debated these issues.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/