The grammar you think might make more sense is clearly broken, it does
not produce
++a[i]
or
x.y.z--
Why are you trying to change the grammar?
/be
Joseph Spencer wrote:
It's an honor to get replies from you guys!
I feel more educated now about the grammar, and the negative lookahead
for { makes sense now for ExpressionStatements as I didn't realize that
object literals weren't considered ExpressionStatements.
Would the following make more sense for UnaryExpressions?
PostfixExpression:
Identifier [no LineTerminator here] ++
Identifier [no LineTerminator here] --
PrefixExpression:
++ [no LineTerminator here] Identifier
-- [no LineTerminator here] Identifier
UnaryExpression:
LeftHandSideExpression
PostfixExpression
PrefixExpression
delete UnaryExpression
void UnaryExpression
typeof UnaryExpression
+ UnaryExpression
- UnaryExpression
~ UnaryExpression
! UnaryExpression
-Joe
On Thu, 2012-08-30 at 07:15 -0700, Brendan Eich wrote:
From "Joseph Spencer"<[email protected]>
ExpressionStatement:
Is the prevention of the token { an error in this context? Initially I
thought it was to give parse flow over to the Block Production, until I
realized that the following 'should' be a valid ExpressionStatement:
{a:5}?5:4;
The spec uses lookahead restrictions on top of an LR(1) validated (ES3 era,
needs revalidation) grammar. This is by design, not an error, and yes, it
intentionally makes expression statements such as
{lol:42} ? "always" : "never";
be early errors.
The simplicity and tried-and-true LR validation are worth it. Anyone being
clever can parenthesize. But of course your example is contrived, and it's rare
but not unheared of to want { at start of an expression statement.
Same goes for 'function', and IME that lookahead restriction bites a bit more
often, but people know to parenthesize.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
