Further, how would this interact with eval introducing (or in
some systems even removing) lexical bindings?
Disclaimer 1: the Berkling-style systems I'm familiar with did
not support eval, so I cannot argue from experience here
Disclaimer 2: the reason for this was that unlimited reflection
support breaks all equational theories about programs
(eg toString can distinguish otherwise semantically
equivalent programs, so only identical programs can be
considered equal if reflection is taken into account) and
equational reasoning was core to reduction languages
Eval already breaks lexical scoping, so there is little hope of
it having no interactions with extensions of lexical scoping.
One might limit "eval('code')" not to have any effect on
the context's lexical scope chain, but that would indeed
limit eval's functionality (the eternal conflict between
expressiveness and reasoning). Limiting eval/toString
to be unaffected by the context's local scope chain would
also be possible, but again, that would mean changing
a lot of code.
Since all that an implementation or programmer has to
go with in the presence of eval is the lexical scope chain
at any point of execution, adding protection is probably
not going to make matters worse wrt eval. Similarly,
toString can already distinguish between codes that
differ only by renaming.
Is that sufficiently vague / reassuring?-)
Nevertheless this 35-year-old idea seems fresh in the
context of ECMAScript development, and worth
thinking about, so thanks for bringing it up.
Always happy to promote a good idea!-)
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
