Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)
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
More information about the Squeak-dev