Allen Wirfs-Brock <mailto:[email protected]>
January 31, 2012 9:20 AM
But it's an issue that I'ver been thinking about since the last meeting.
The basic difference between non-strict direct eval and strict direct
eval is that strict creates a new nested environment contour that is
used as both the VariableEnvironement and LexicalEnvironment while
non-strict uses the currently active Variable/Lexical environment.
It there are two possible semantics for non-strict eval with lexical
declaration that I have come up with are:
1) same as ES5, it currents it uses/extends the current Variable and
Lexical Environments
function f() {
// variable environment
function xVarEnv() {return x}
{
//lexical environment
print(xVarEnv()); //should be: undefined
eval("var x=1"); //create in the variable environment
print(xVarEnv()); //should be: 1
eval("let x=2"); //create in the lexical environment
eval("print(x)") //should be: 2
print(x); //should be: 2
print(xVarEnv()); //should be: 1
}
print(xVarEnv()); //should be: 1
)
(note that the most interesting example have an inner block)
(Indeed.)
I don't like this because we make a pre-strict variation on 'let' that
perpetuates the dynamic scope injection flaw in eval, whereby it can
pollute its caller's scope with fresh bindings. This is just evil and I
wish we'd never standardized it in ES1 for 'var'. I see no good coming
from extending it to 'let' and 'const'.
And 'function' in block? That's a different case again because it
wouldn't hoist. Indeed direct eval('function f(){...}') in non-strict
code is analogous to the SpiderMonkey conditionally-compiled,
dynamically-bound function in sub-statement pre-ES3 extension we are
trying to kill.
I think (2) is the best course. It "mixes" differently, but in a
stricter direction.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss