Lex wrote:
> The scheme was really very similar to dynamic method lookup, 
> which is especially neat if you name the variables 
> "dynamically-bound variables" instead of "thread-local variables".

I think this gets right to the heart of the issue.  We're just looking
for something a lot cleaner than "Processor activeProcess processGlobals
at: #Whatever".  We already have dynamically bound variables...temp vars
and instance variables are dynamically bound (to statically defined
structures).  Is it useful to extend this such that we can dynamically
bind process globals?  Should we declare process globals by subclassing
Process?  Should we then require that methods be compiled to run in the
context of a specific class of process (with the default being Process
of course) so that we can bind the slot of the process global at compile
time?  Then what happens when we execute a method that references a
Process global, but our current process is not what was expected at
compile time?

One bit of frustration in using process globals is that the methods that
access them are not always obvious, and when trying to evaluate methods
that expect certain process globals to be present, it's not always easy
to know exactly what is expected of the caller (in terms of setting up
process globals).  It would be nice for formalize this a bit.

- Stephen