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.


The dynamically-bound variables I made to solve this are just like
global variables in Common Lisp.  To a first approximation, you can
do:

	Smalltalk setVariable: #World to: aRestrictedWorld during: [...]

That's the analog to Lisp: setting one variable at a time.  However,
my system actually installed a whole table of global variables at
a time, more like:

	island installYourselfDuring: [ ... ]

where "island" includes a table of globals among other things.

This allows the island to have its own "Array" binding which is
different from the binding any code outside the block will see.
If the island executes:

	Array := dangerousArraySubstitute

or even

	Array := nil

then it cannot harm anyone who is using the other Array bindings.


-Lex