Notice though, that I started the thread that explanation were _incomplete_. I don't say they are completely were wrong. Again, they were just incorrect in respect of the SyntaxError _reasons_. Of course if the explanation is started from: /"we need to have a function expression here, and therefore it should be and expression statement, and therefore we need to to surround it, since an expression statement cannot begin with a `function` keyword..."/, then of course it's correct. But the explanation /"the SyntaxError is because the expression statement cannot start with a `function` keyword"/ is wrong. And exactly about it I was talking.

Dmitry.

On 02.01.2011 0:52, Dmitry A. Soshnikov wrote:
On 02.01.2011 0:27, Garrett Smith wrote:
On 1/1/11, Dmitry A. Soshnikov<dmitry.soshni...@gmail.com>  wrote:
On 01.01.2011 4:01, Garrett Smith wrote:
On 12/31/10, fernando trasvina<trasv...@gmail.com>   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.


True-true ;)

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?


The thing is that the _parser_ treat it as a FD. Your (mine, other) meaning is irrelevant here. For the parser it's a FD and it fails because doesn't see a name for the FD.

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.


And this is exactly a correct explanation (which I brought) and which wasn't mentioned before. Exactly a grouping operator is the case which incorrectly was treated as a call parens (`Arguments` production).

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.


I glad that you see it.

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

Again, it's only for you (incorrectly) it's a function expression. The parser treats it as a FD and fails because the name of the _FD_ is missing. I.e. it tries to create it on entering the context and to place into the VE. Do you see the goal? It's FD, not FE and that exactly I say and correct previous _wrong_ (including yours) explanations.

  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.


FD. And I guess at this step you've already understood it.

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?

That exactly I did, nope? And it wasn't made before. Before all explanations started with irrelevant "expression statement cannot begins with a `function` keyword, that's why it's a SyntaxError". On what I say, that the SyntaxError is not because of this, but because of either missing of the FD's name, or because of an empty grouping operator.

Neither your explanation nor my explanation is wrong.

The previous explanations (including yours) are not correct in respect of the _reason_ of a SyntaxError. But expression statement is relevant here only in that respect that exactly to the FE the function should be (manually) transformed. I.e. `ExpressionStatement` (and all related stuff) is derived. FD and its issues are the _main_.

Though calling a
correct explanation wrong is wrong. So don't do that.


I hope at this step I clarify the things to you.

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.

You understood what I meant. I choose not to explain much here ;)

Dmitry.

--
To view archived discussions from the original JSMentors Mailman list: 
http://www.mail-archive.com/jsmentors@jsmentors.com/

To search via a non-Google archive, visit here: 
http://www.mail-archive.com/jsmentors@googlegroups.com/

To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com

Reply via email to