Scoping of non-strict direct evals in parameter expressions
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see earlier eval
binding}; 84)
) {
console.log(x); // ? outer , 1, or 84?
}
f();
In other words, for non-strict functions, in what scope does should a direct
eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope contour
that is separate from the body scope (and the environment for the body scope
doesn't even exist during parameter expression evaluation. Also remember that
legacy non-strict direct evals within functions create vars (and functions) in
the variable scope of the function (which is the same as the body scope).
I propose, that for scoping purposes, we treat such evals (parameter expression
+ non-strict + direct) as if they were strict evals. That means that all
declarations created by the eval code are created in a new environment record
that is discarded when the eval completes. Basically, it means that evals in
parameter expression can't create bindings that are visible outside of the eval.
Also, note that I'm not proposing that strict mode rules such as banning 'with'
be applied to the body of the eval. I'm just talking about the declaration
scoping rules. This introduces a sort of micro-mode but the alternatives see
less desirable. They are 1) figure out a semantics of declarations injected
into the function from parameter list evals; 2) force parameter list direct
evals into full trict mode. The first is hard, complex, and probably
pointless; the second is still a sort of micro-mode, seems less aligned with
the likely user intent, and I think will actually be harder to specify.
Thoughts?
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Scoping of non-strict direct evals in parameter expressions
On Wed, Dec 3, 2014 at 2:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see earlier
eval binding}; 84)
) {
console.log(x); // ? outer , 1, or 84?
}
f();
As it's now, it should be 84 seems, but with creation of `x` with the value
`1`, then printing `can see earlier eval binding`.
In other words, for non-strict functions, in what scope does should a
direct eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope
contour that is separate from the body scope (and the environment for the
body scope doesn't even exist during parameter expression evaluation. Also
remember that legacy non-strict direct evals within functions create vars
(and functions) in the variable scope of the function (which is the same as
the body scope).
I propose, that for scoping purposes, we treat such evals (parameter
expression + non-strict + direct) as if they were strict evals. That means
that all declarations created by the eval code are created in a new
environment record that is discarded when the eval completes. Basically, it
means that evals in parameter expression can't create bindings that are
visible outside of the eval.
Yeah, since defaults params and the the whole intermediate params scope is
the whole new semantics, we can easily make this strict eval evaluation in
its isolated environment. Seems the easiest solution, so eventually the `x`
will be `outer`, and `can't see...`.
Dmitry
Also, note that I'm not proposing that strict mode rules such as banning
'with' be applied to the body of the eval. I'm just talking about the
declaration scoping rules. This introduces a sort of micro-mode but the
alternatives see less desirable. They are 1) figure out a semantics of
declarations injected into the function from parameter list evals; 2) force
parameter list direct evals into full trict mode. The first is hard,
complex, and probably pointless; the second is still a sort of micro-mode,
seems less aligned with the likely user intent, and I think will actually
be harder to specify.
Thoughts?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Scoping of non-strict direct evals in parameter expressions
On 3 December 2014 at 23:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see earlier
eval binding}; 84)
) {
console.log(x); // ? outer , 1, or 84?
}
f();
In other words, for non-strict functions, in what scope does should a
direct eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope contour
that is separate from the body scope (and the environment for the body scope
doesn't even exist during parameter expression evaluation. Also remember
that legacy non-strict direct evals within functions create vars (and
functions) in the variable scope of the function (which is the same as the
body scope).
I propose, that for scoping purposes, we treat such evals (parameter
expression + non-strict + direct) as if they were strict evals. That means
that all declarations created by the eval code are created in a new
environment record that is discarded when the eval completes. Basically, it
means that evals in parameter expression can't create bindings that are
visible outside of the eval.
Also, note that I'm not proposing that strict mode rules such as banning
'with' be applied to the body of the eval. I'm just talking about the
declaration scoping rules. This introduces a sort of micro-mode but the
alternatives see less desirable. They are 1) figure out a semantics of
declarations injected into the function from parameter list evals; 2) force
parameter list direct evals into full trict mode. The first is hard,
complex, and probably pointless; the second is still a sort of micro-mode,
seems less aligned with the likely user intent, and I think will actually be
harder to specify.
Thoughts?
Sounds good to me. FWIW, I wouldn't consider this a micro-mode. It's
just scoping: every default expression simply executes in a new
(declaration) scope. You don't even need to change the rules for eval
itself, it can be specified completely independent of what the
expression is. If you model it that way, then it automatically extends
to future do-expression as well (which might also be abused to create
'var's in default expressions).
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
