Annex A of 5th Edition

[Joseph Spencer]

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" <js.developer.undefined at gmail.com>
> > 
> > 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