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
