Eval-invisible let bindings

Lars Hansen lhansen at adobe.com
Thu Dec 6 03:53:06 PST 2007

On Dec 6, 2007 12:25 PM, Igor Bukanov <igor at mir2.org> wrote:
> On 06/12/2007, Lars Hansen <lhansen at adobe.com> wrote:
> > Such an implementation only needs to detect direct
> > uses of eval, as specified in ES3 and elaborated in ES4.   (ES4
> > specifies the meaning of strictly more uses of eval than ES3, and
> > requries that EvalError is thrown in other cases.)
> This is good in theory, but for compatibility reasons the
> implementation may be forced to support the indirect eval. For
> example, at least recently some Goggle's pages contained var e=eval;
> to compress the code.

And that use case is explicitly allowed by ES4, which assigns specific
semantics to it, namely that the eval *function* performs evaluation in
the global scope of its definition, not in the local scope of its call.
Only "eval" as an operator performs evaluation in the local scope of its
call, and in that case it is always lexically apparent whether a call
may be an invocation of the eval operator.  (Modulo surrounding uses of
"with" and "eval", and open namespaces.  In practice, it may be
necessary to perform a lookup to see if the name "eval" actually
references the initial binding of the eval function.  This should be

> So I do not see how specifying more stricter
> cases for ES4 would change the situation in practice. Hence this idea
> to make at least new ES4 features immune from eval universality.

The issues, including issues of backward compatibility, have been
discussed extensively in TG1, and even though there may exist some ES3
implementations that allow eval to be used in a way that is not
conformant with the current ES4 proposal, and even though there may be
programs that depend on that behavior, it is not believed to be a
problem in practice.  There are ES3 user agents, like Opera, that
restrict eval in various ways.  Opera employees have been participating
in this discussion and based on their experience with bug reports
resulting from (or rather not resulting from) restrictions in Opera,
appear to believe that the current ES4 spec is sufficient.

(IMO the problem with eval cannot be worked out satisfactorily by making
language features invisible to it, but by restricting its applicability
as much as possible.  Backward compatibility is the real test, to be
sure.  So far, TG1 believes we have that under control.)


More information about the Es4-discuss mailing list