On 1/1/11, Dmitry A. Soshnikov <[email protected]> wrote:
> On 01.01.2011 4:01, Garrett Smith wrote:
>> On 12/31/10, fernando trasvina<[email protected]> wrote:
>>
>>
>>> why this is not treated the same way as:
>>>
>>> function(x){}(1);
>>>
>> That is a SyntaxError. The most recent message on this thread (mine),
>> explains that the production for ExpressionStatement explicitly
>> forbids an ExpressionStatement to begin with the function keyword.
>>
>
> Garret, that exactly about what I was talking (you don't think that I
> opened this thread just to notice again about "expression statement
> cannot begin with a function keyword, bla-bla", right?)
>
> The thing, again, is that _all_ previous explanations (books, c.l.js,
> articles, ect), including your current explanation to fernando, were
> (and are if now) _wrong_.
No, my explanation is not wrong.
The main thing is absolutely in not that
> ExpressionStatement which cannot begin with a `function` keyword!
>
Nope, that's part of it.
> The correct answer is that it's function declaration! And from this
> step, there are two reasons of the issue.
>
No, that is not true at all. It is not a FunctionDeclaration. It is
nothing, and so unless there is a syntax extension going on, it is a
SyntaxError.
> In your case (example above) the `SyntaxError` is because the _name of
> the FD_ is missing:
>
You call it an FD but how can it be an FD when there is no identifier?
> function foo(x) {}(1);
>
FunctionDeclaration.
> Because the example above (after I added the name) _synthetically_ is
> absolutely _correct_. But it's obviously is "not correct" semantically.
It's an FD followed by Grouping Operator.
> We expect that the last parentheses are about _call_ (`Arguments`
> production). But they are not! It's just a second production which
> follows the first one -- it's a grouping operator with expression `1`
> inside which is follow the correct FD. The example below shows it:
>
Yep.
> alert(foo); // function, it's FD
>
Yep.
> function foo(x) {
> alert(x);
> }(1); // there's NO call here!
>
Right.
> foo(2); // and this is already a simple call, 2
>
> So the second reason of the `SyntaxError` is exactly in the _empty
> grouping operator_:
>
> function foo(x) {
> alert(x);
> }(); // it's not a call again, but a grouping operator, SyntaxError
>
> It's a SyntaxError as with any empty grouping operator:
>
> (); // SyntaxError
>
> (1); // But this is OK, a grouping operator with the expression `1` inside
>
All of those are true. None of those things support the argument that
a SyntaxError is to be expected from ferenando's example.
You raise a good point that the lexical scanner will see "function"
keyword, see that as an FD, and then when there is no Identifier, will
err.
Then again, if the expectation of fernando's example is that the
anonymous, misplaced (and thusly syntactically invalild) function
expression is going to be executed immediately, then it woul have to
be based on the (mis)understanding that that "function" (which it
can't ever be because it's not syntactially valid), is a
FunctionExpression.
Now if one is looking at that "function(x){}(1)" as a
FunctionExpression, doesn't it make sense to explain that it is not
parsed as a FunctionExpression?
Neither your explanation nor my explanation is wrong. Though calling a
correct explanation wrong is wrong. So don't do that.
> At this step we do not have any mentioning about that
> "ExpressionStatement cannot begin with a `function` keyword". We reach
> it when have exactly an expression statement. E.g.:
>
> if (true) function foo() {...}
>
Careful. It's valid to have statements as Program code, e.g.
void function(x){alert(x);}(1)
SourceElements include a Statement.
> Which we all know is handled (via extension) by all implementation here
> and there is no any syntax error here.
>
> Reread my explanation mentioned at the beginning of the thread
> (currently only it is correct; also Ben Allan edited his article on
> "Immediately Invoked Function Expression", IIFE, which also has now the
> correct explanation).
>
> Please spread this correct explanation and correct all other which were
> wrong.
>
>> Please do not top post.
>
> Leave this choice for a participant how to answer.
I'd rather encourage good communication. I hope that you don't mean to
encourage poor communication.
--
Garrett
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
