12.3.4.1 "Runtime Semantics: Evaluation"
says:
A CallExpression whose evaluation executes step 4.a.vii is a direct eval.
Two things:
(1) For a given CallExpression, whether its evaluation executes that step can vary between evaluations. (ArgumentListEvaluation might return an abrupt completion, or it might not.) So does this mean that the CallExpression is sometimes a direct eval and sometimes not?
(2) Some early error conditions (which must be enforced before code is evaluated) rely on detecting direct evals. But given the above, direct evals cannot be statically detected.
If you change "4.a.vii" to "4.a.i", that might make some of this go away, but you'd still be left with a definition of direct eval that is not actually usable for early error detection.
Whether or not a call expression is a direct eval cannot be statically determined. Unfortunate, but that is a design decision made in the Es5 days.
I can't find any early errors that depend upon static identification of a direct eval. The rules in 15.1.1 are referring to an eval invocation that has already passed through 4.a.vii (or not). It is the direct (or indirect) eval it self that is applying that rule, so it knows whether or not it is a direct eval.
(In reply to Allen Wirfs-Brock from comment #1)
> Whether or not a call expression is a direct eval cannot be statically
> determined. Unfortunate, but that is a design decision made in the Es5 days.
Okay. Then it might be clearer for 12.3.4.1 to say:
An evaluation of a CallExpression that executes step 4.a.vii
is a direct eval.
I.e., being (or not being) a direct eval is a property of an evaluation, not of the static CallExpression.
> The rules in 15.1.1 are referring to an eval invocation that
> has already passed through 4.a.vii (or not). It is the direct (or
> indirect) eval it self that is applying that rule, so it knows whether or
> not it is a direct eval.
Ah, got it.
fixed in rev39 publication draft