Hi Mark,

"Mark S. Miller" <markm at caplet.com> wrote:
> >inform us on scoping of names in E? 
> 
> Strictly absolutely only lexical scoping according to lexical nesting, just 
> as Scheme without fluid variables.
> 
> Scheme's fluid variables are much like Common Lisp's dynamic variables -- 
> both are dynamically scoped. Fluid variables are a bit better from a 
> capability perspective, but not better enough. When designing Joule 
> http://www.agorics.com/Library/joule.html , E's most important and direct 
> ancestor, Dean and I both thought we had a few cases that justified 
> genuinely justified dynamic scoping. Although, as I recall it took Norm 
> months to pry our fingers loose from this idea, he did prod us to go through 
> each of these cases and see that the lexically-scoped answer was simply 
> better on all dimensions we cared about -- security, convenience, 
> understandability -- then the dynamically scoped answer.

What about exception handlers?  Don't these require dynamic scope?

> Some of these better answers involved Joule's Type Extension feature, which 
> is very similar to Anthony's Class Extensions. Joule's Type Extensions, like 
> the selectors of Jonathan Rees' T language which preceded it, was itself a 
> purely lexically-scoped notion. In order to solve these problems in a 
> similar manner, Anthony's Class Extensions will need to be made lexically 
> scoped as well. Fortunately, I think is should be straightforward.

I believe my class extension design (no implementation yet) is already
lexically scoped.  A class extension is just like any other class.  A
client class can only use another class if it is in the client's pool (lexical scope).
(My class extension paper is at
http://minnow.cc.gatech.edu/squeak/SharedSmalltalk).

Cheers,
Anthony