Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)

Lex Spoon lex at cc.gatech.edu
Wed Jan 29 08:28:01 UTC 2003

"Stephen Pair" <spair at acm.org> wrote:
> Avi Bryant wrote:
> > Well, yeah. :) I thought that's what you meant.  Obviously 
> > there's no reason you can't have the same interface to both 
> > implementation approaches.  I currently use an exception 
> > based dynamic scope that looks like
> > 
> > 
> > DynamicContext bind: #foo to: 42 during:
> >   [
> >     self assert: #foo dynamicValue = 42
> >   ]
> > 
> > self assert: #foo dynamicValue isNil.
> Actually, I rather like the #dynamicValue pattern.  Why not this then:

Best of all seems to be to tweak the compiler a little.  If we had
dynamically-bound global-scope variables, how often would we want to use
statically-bound global-scope variables?  I can't think of a single
case, and switching seems to quietly make some other things work better.
 For example, switching World to be a dynamic variable will allow
multiple worlds to coexist with very little code changes.

In Islands, the syntax is like this:

	World   "a dynamically-bound variable"

	!World  "an old-fashioned statically-bound variable.  only allowed in
rare privilaged methods"

I didn't hit on the wonderful idea of having the compiler send #value;
instead, the dynamic variable turned into bytecodes something like this:

	!Smalltalk readVariable: #World

Either way should be fine, though.  I think you want *some* mechanism to
break out, within the method.  If nothing else, it is nice to do things

		!PrivilagedEnvironment clamp: [ ".. do some privilaged stuff.." ]

But maybe I just haven't thought enough about how to get rid of the last
few instances.


More information about the Squeak-dev mailing list