statements that could be expressions?
mikesamuel at gmail.com
Thu Jun 2 16:27:37 PDT 2011
2011/6/2 Mike Samuel <mikesamuel at gmail.com>:
> 2011/6/2 Waldemar Horwat <waldemar at google.com>:
>> On 06/02/11 13:43, Mike Samuel wrote:
>>> Yes. That grammar is a subset of the grammar that results from
>>> replacing the 11.1.6 ' PrimaryExpression : "(" Expression ")" '
>>> production with
>>> "(" GroupElement GroupElements ")"
>>> where GroupElement is defined as any Statement except for Block and
>>> EmptyStatement without a terminal semicolon, and GroupElements is
>>> defined thus
>>> GroupElements : empty
>>> | ";" GroupElement GroupElements
>>> but I thought it was easier to reason about ambiguity and locality of
>>> spec changes for that subset.
>>> 2011/6/2 Waldemar Horwat<waldemar at google.com>:
>>>> Did you mean to disallow an expression as the first statement in your
>> There's no reason to disallow expression statements from the beginning, and
>> it's really odd that you can write
>> (if (a) b; x = 2; c)
>> but not:
>> (x = 2; if (a) b; c)
>> There are other issues, though, with expression statements that begin with
>> the word "function", but those happen regardless of whether the expression
>> statement is first. For those, are you declaring a named function (in what
>> scope?) or returning a function value?
> Quite right. I knew I had left out all declarations in my first pass.
Actually, there's no ambiguity. FunctionDeclaration is not part of
Statement. It's part of SourceElement.
More information about the es-discuss