On Sun, Jan 18, 2009 at 8:47 PM, Brendan Eich <[email protected]> wrote:
> On Jan 18, 2009, at 6:03 PM, Mark S. Miller wrote:
>
> A related difficulty, not addressed by the above spec, is shadowing. Does
>> the following program contain a direct call to eval (i.e., a use of the
>> "eval operator")?
>>
>> function foo(eval, str) {
>> return eval(str);
>> }
>>
>
>
> [...] The standard approach is to check for a callee named 'eval' and emit
> a distinguished instruction which acts like the generic call instruction.
> [...] checking for a known identifer when parsing call expressions, [...] So
> the above eval call would be "apparently-direct", [...]
>
> Note that there's no way at runtime to change an apparently-direct eval
> into an indirect eval call. But an apparently-direct eval can turn into a
> plain old call.
Good.
The eval variable being called here is not an alias for the "eval" property
>> of the global object, though it may or may not have the same value. If the
>> answer is that this is not a direct call,
>>
>
> That's the wrong answer -- it should be direct purely because the callee
> name is 'eval'.
>
So the use of "property" in the spec:
If strict mode code uses the value of the eval property any way other than
> as a direct call (that is, other than by the explicit use of its name as an
> Identifier which is the MemberExpression in a CallExpression), or if the
> eval property is assigned to, an EvalError exception is thrown.
>
means the original *value* of the global eval property (in which case the
statement of the assignment constraint is wrong)? And "its name" above means
specifically "eval", whether referring to a property or a local variable?
since the defining occurrence is local, then what about the second "eval"
> in the following code?
>
> function foo(str1, str2) {
> eval(str1);
> eval(str2);
> }
>
Same answer -- these are two "direct" eval calls by the compiler's lights.
>
Good.
>
> Since foo may be called as foo('var eval = f', ..), the second eval may
>> refer to a local or to a global eval. These ambiguities defeat the goal of
>> distinguishing direct from indirect calls.
>>
>
> Not in practical implementations that nevertheless do no expensive
> analyasis, as sketched above.
>
Given your other answers, I don't think we have a problem here.
> Though the above specific problem cannot occur if foo is strict, I propose
>> that, for all code, one may not define a local variable named "eval".
>>
>
> This is unnecessary, and I'm not sure it's sufficient given your
> assumptions.
I think I'm happy with your earlier assumptions above; in which case it
would be sufficient to prohibit defining local variables named "eval".
> But we shouldn't have to worry about any shadowing or rebinding issues if
> we can specify what popular implementations do.
>
What Firefox current does (3.0.5):
function foo(a, b, c) { return a(b); }
foo(eval, 'c', 42); // returns 42
>From my understanding of your statements above (as well as previous
conversations), can we agree that FF's current behavior violates both what
ES3.1 does and should specify?
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
