eval(a, b) parsed as CallExpr instead of as EvalExpr

[GoogleCodeExporter]

15.1.2.1.1 in the ES5 spec does not make the determination of whether an 
eval is an operator or function dependent on the number of parameters 
passed to it.

Currently
   eval('foo')
is an EvalExpr, but
   eval('foo', 'bar')
is not.

Original issue reported on code.google.com by mikesamuel@gmail.com on 8 Jan 2010 at 6:29

[GoogleCodeExporter]

I just noticed that tomvc submitted a change intentionally to add a 
arguments.length 
=== 1 check.  What is the reasoning behind that?

Original comment by mikesamuel@gmail.com on 8 Jan 2010 at 6:55

[GoogleCodeExporter]

Failing to get a satisfying answer from es-discuss, MarkM and I had another 
look at
this and decided it would make most sense to have the parser generate an 
EvalExpr no
matter the number of arguments passed to eval. It seemed like a strange 
restriction
for the parser to check the number of arguments. Furthermore, the spec does not
mention # of arguments when defining what a 'direct call to eval' means.

Change reverted in r136.

Original comment by to...@google.com on 15 Jan 2010 at 2:18

• Changed state: Fixed

[GoogleCodeExporter]

For reference, the relevant es-discuss thread is 
https://mail.mozilla.org/pipermail/es-
discuss/2010-January/010512.html .

Original comment by mikesamuel@gmail.com on 15 Jan 2010 at 2:22