Proposal: Squeak-E = Squeak x Kernel-E
ajh18 at cornell.edu
Tue Jan 28 19:16:22 UTC 2003
"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
More information about the Squeak-dev