"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
like:

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


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


Lex