On Sun, Jan 2, 2011 at 3:14 PM, Lasse Reichstein <[email protected] > wrote:
> On Fri, 31 Dec 2010 14:46:37 +0100, Dmitry A. Soshnikov < > [email protected]> wrote: > > So, why does this code produces a SyntaxError: >> >> function () { >> ... >> }() >> > ... > > Try to provide as much complete explanation as possible. Also try to >> answer without cheating ;) >> > > Because an ExpressionStatement may not start with the token "function", and > a > FunctionDeclaration may not omit the function name identifier, so there is > no > matching rule in the syntax. > > Yes, the thing I wanted to underline, that the parser (because of "ExpressionStatement" cannot begin with a `function` keyword) always treats such production as a `FunctionDeclaration`. And that the `SyntaxError` relates to two possible cases. In first case, yes, it's a missing name of the FD. But if we add the name, there are still the syntax error. Thus, notice that the FD itself is parsed and created normally. > With the variable name, the first part does match a FunctionDeclaration, > but > there is no rule that allows an opening parenthesis after a function > declaration. > > And this is the second case which I wanted to clarify and correct. The widespread meaning was that the parentheses at the end are about the _call_. However, I wanted to predict the questions such as: Why in the following case there is a SyntaxError (accepting that we have a name of the FD): // SyntaxError function foo(x) { alert(x); }(); And if we "pass the argument", then there is no error: // SyntaxError function foo(x) { alert(x); }(1); And what I wanted to notice, that this _isn't a call_ at all, but two separate productions: a correct function declaration, and the grouping operator which follows the FD. I.e. the issues (SyntaxError) are not in `ExpressionStatement` itself, but two separate things: (1) FD without a name and (2) a grouping operator without an expression inside. And the `ExpressionStatement` just helped us in respect of determining that if a production begins with a `function` keyword, a parser always tries to parse a FD. And only after that, when we say that we need that the semantics of the parentheses at the end reflect exactly a _call_, we mention a function expression (FE) which is a case of an ExpressionStatement. Then we already propose a way of transformation a FD to FE (to force the parse think that this is exactly FE); one of such widespread ways -- is a grouping operator which surrounds the function. Or more indirectly: The syntax generally requires only one token of > look-ahead to > identify the production to use. It disallows an ExpressionStatment from > starting > with "function" (or "{") to avoid ambiguity with FunctionDeclaration (or a > statement > block). That means that the above cannot possibly be detected as an > immediate function > call, but only as a FunctionDeclaration with garbage at the end. > Yes, though I'd add: this "garbage at the end" is a garbage until it's a grouping operator without an expression inside. When we add the expression, e.g. (1), which _incorrectly_ always was treated as a _call_, we transform the garbage in _syntactically_ correct production. Of course, _semantically_, it's still the "garbage", since the meaning is not that we expected (i.e. not a call of function, but just FD + following grouping operator). So, concluding, exactly the fact that this is a _grouping operator_ in this case appears for the parser (and not the call, `Arguments` production), and exactly it's one of the syntax error reasons. Dmitry. > > /L > > > -- > 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]<jsmentors%[email protected]> > -- 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]
