Proposal: Squeak-E = Squeak x Kernel-E

Anthony Hannan ajh18 at
Mon Jan 27 01:37:33 UTC 2003

Lex Spoon <lex at> wrote:
> On Sun, Jan 26, 2003 at 12:21:58PM -0800, Mark S. Miller wrote:
> > At 10:33 AM 1/26/2003 Sunday, Lex Spoon wrote:
> > >        - dynamically-scoped variables, so that the "global" variables aren't
> > >          shared
> > 
> > It's the area I'd worry about first. A capability language probably 
> > shouldn't have anything one would think to call "global" variables, even 
> > with the scare quotes. I don't know what you mean by "dynamically-scoped 
> > variables", but if it's anything like Lisp1.5's or Smalltalk-72's 
> > dynamically-scoped variables, that'd be even worse.
> It's simple, and I believe it's a good solution.  I'd be interested
> to here your concern about it and how one might do better.
> Without some kind of  global variables, you don't have Smalltalk.  Consider
> the globals "Array" and "World", for example.  How do you get access
> to these things?  Fundamentally, your code is just going to say "I want
> an Array class" or "I want access to the current graphical world".
> No matter how much syntax you clutter it with, this is conceptually
> a global variable.

Array and World don't have to be global, they can just be given to
classes that need them.  For convenience, they can be grouped into
pools.  Methods would have access only to objects in the pools held by
its class (and superclasses).  Giving a pool to a class is equivalent to
giving the class capabilities to the pool's objects.  You can even
restrict the capabilities by only putting proxies in the pool that only
understand certain messages like #new (versus #addSelector:withMethod:).
 I describe this pool concept in my SharedSmalltalk paper at


More information about the Squeak-dev mailing list