Annex A of 5th Edition

[Joseph Spencer]

My apologies on that one.  I meant to type the following:

PostfixExpression:
    LeftHandSideExpression [no LineTerminator here] ++
    LeftHandSideExpression [no LineTerminator here] --

PrefixExpression:
    ++ [no LineTerminator here] LeftHandSideExpression
    -- [no LineTerminator here] LeftHandSideExpression

It appears to me that as currently written the following is considered
valid sytax:

++++someVar;

I hadn't thought about es3 compatability though, so I could see the
reasoning in keeping it as is.
As a noobie (and most likely someone in dire need of correction
;) approaching this , it seems to
me that there are a few loose ends in the grammar.  For instance, the
following statements seem
allowable by the grammar as currently written:


++typeof someVar;
++new Date();
++null;

My knowledge is lacking on this though, so I am probably missing something.
 I was surprised
to find that the following is valid syntax and a perfectly legal
FunctionDeclaration, but throws a
ReferenceError when executed:

function failPlease(){
   alert(++++a);
}

-Joe


On Thu, Sep 6, 2012 at 7:32 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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"<js.developer.**undefined at gmail.com<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
>>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120906/9409d2d4/attachment.html>