Proposal: Squeak-E = Squeak x Kernel-E

cg at cg at
Tue Jan 28 08:36:44 UTC 2003

Robert Withers <squeak-dev at> said:
>Actually, let's define Array first.  ;-)
Good idea.

>Array is the name for a object of class Class.  Global refers to the 
>visibility of that named binding inside of the parser and stack.   The 
>key is that it is the naming system, within Smalltalk.
In fact, Array is two names: the 'intrinsic' name of the class, and the
name for a binding to find the class. We're interested in the latter bit

>A compiler's access to names should be scoped to the context it 
>operates in.  That context is the Class instance, and it's 
>superclasses.    An import of name scopes is the typical way that a 
>class can get to other names.
Why the compiler? With the whole, err, 'war' on dynamic scoping raging on
in the other thread between Stephen and Avi ;), I think there's enough
complexity already. Can we leave out the compiler for now? AFAIK,
external (class) references are stored in compiled method in a form that
makes late binding possible, so - again AFAIK - we can play every trick
we want. 

What I really want to concentrate on is what is the best way of scope
for a Squeak with the capabilities of E (pun intended):
1. Global (Squeak)
2. Per process (Stephen)
3. Stack visibility (Avi)
4. Per object
5. Static

4. is an alternative where the sender contains the scope. I'm not sure
it is useful, I'm just trying to make a complete list of alternatives
here. Seems a bit mundane compared with the high-flying discussions
we've been seeing here on the list, but somehow I feel that the best
approach here is strip terminology, list alternatives, and make a choice

5. is probably even less useful, where the compiler determines scope.

Mark, if you're still with us, could you answer my questions two clicks
up this thread or otherwise inform us on scoping of names in E? 

Cees de Groot          <cg at>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo

More information about the Squeak-dev mailing list