In what ways does the following "eval" regularity break?

Brendan Eich brendan at mozilla.com
Thu Oct 30 00:15:29 PDT 2008


On Oct 29, 2008, at 11:23 PM, Mark S. Miller wrote:

> The intent of ES3's eval operator is clearly that it at least
> approximate the following result:
>
> For certain triples of source code text:
>    <some code a> <some code b> <some code c>
> is equivalent to
>    <some code a> eval("<some code b>") <some code c>
>
> By placing quotes around <some code b>, I am not suggesting literally
> surrounding it with quotes, but rather turning it into a string
> literal whose value is the original code string.
>
> Certainly, we understand that <some code b> must be balanced and must
> either be an expression, a statement, a block, or a function body.

It must be a Program, grammatically:

15.1.2.1 eval (x)
When the eval function is called with one argument x, the following  
steps are taken:
1. If x is not a string value, return x.
2. Parse x as a Program. If the parse fails, throw a SyntaxError  
exception (but see also section 16).

A program is not the same as a function body, grammatically:

12.9 The return Statement
Syntax
ReturnStatement :
     return [no LineTerminator here] Expressionopt ;
Semantics
An ECMAScript program is considered syntactically incorrect if it  
contains a return statement that is not within a FunctionBody.


> A case I'm particularly interested in is when <some code b> is the
> body of a function. Other than the return issue illustrated above, in
> what other ways does ES3's eval() violate this regularity?

Maciej pointed out the lack of DontDelete in variable object bindings  
created when entering an execution context for eval code. This applies  
to function and var both!


> In a similar vein, in what ways might
>
>    new Function("<some code b>")
> differ in meaning from
>    function(){eval("<some code b>");}
>
> The obvious one: In the latter, <source code b> can refer to
> non-global variable that are in scope at eval's site. What else?

The return restriction, again. The deletable variable object bindings  
issue.

The right thing(tm) I regret not having the time to inject at the  
beginning would be quotations to get ASTs from source text, and an  
eval that took an AST, not a string.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081030/6c7c086d/attachment.html>


More information about the Es-discuss mailing list