Reason for strange ExponentiationExpression & UpdateExpression productions?

[Bradford Smith]

Thanks!
I'll know to look there in future. rwalden takes good notes.

No luck finding an answer to my question #2 though.
Searches tried:
++
increment
decrement
unary
UpdateExpression

On Wed, Jul 20, 2016 at 1:22 PM Jordan Harband <ljharb at gmail.com> wrote:

> https://github.com/rwaldron/tc39-notes/search?utf8=✓&q=exponentiation
> leads me to
> https://github.com/rwaldron/tc39-notes/blob/924122cdc03e9ee2afbe8014193f845bddc6da2d/es7/2015-09/sept-23.md#exponentiation-operator
> which is when that decision was made, iirc.
>
> On Wed, Jul 20, 2016 at 1:04 PM, Bradford Smith <bradfordcsmith at google.com
> > wrote:
>
>> Thanks for the quick response, Jordan. That does make sense for my
>> question #1.
>>
>> Re #2, does anybody know why UpdateExpression loops back up to
>> UnaryExpression?
>>
>> Also, are the reasons for the decisions made when updating the spec
>> documented anywhere?
>> If so, maybe I could find the answer to questions like these myself in
>> future.
>>
>> Thanks,
>> Bradford
>>
>> On Wed, Jul 20, 2016 at 12:55 PM Jordan Harband <ljharb at gmail.com> wrote:
>>
>>> `-x ** y` is absolutely a SyntaxError because of the disagreement
>>> between many programming languages which treat that as `(-x) ** y` and math
>>> itself which treats it as `-(x ** y)`.
>>>
>>> To resolve the debate about "what will users expect", this early syntax
>>> error ensures that programmers get the joy of being required to be explicit
>>> about their precedence, saving countless amounts of time and money spent on
>>> linting rules and style arguments.
>>>
>>> On Wed, Jul 20, 2016 at 12:48 PM, Bradford Smith <
>>> bradfordcsmith at google.com> wrote:
>>>
>>>> Can anyone explain the reasoning behind the strange "leapfrogging"
>>>> behavior of the ExponentiationExpression
>>>> <https://tc39.github.io/ecma262/#prod-ExponentiationExpression> and
>>>> UpdateExpression
>>>> <https://tc39.github.io/ecma262/#prod-UpdateExpression> productions in
>>>> the current spec?
>>>>
>>>> Simplified relevant productions in operator precedence order are:
>>>>
>>>> ExponentiationExpression :
>>>>     UnaryExpression
>>>>     UpdateExpression ** ExponentiationExpression
>>>>
>>>> UnaryExpression :
>>>>     UpdateExpression
>>>>     { delete | void | typeof | + | - | ~ | ! } UnaryExpression
>>>>
>>>> UpdateExpression:
>>>>     { ++ | -- } UnaryExpression
>>>>     LeftHandSideExpression { ++ | -- }
>>>>
>>>> Things that seem weird about this are:
>>>> 1. '-x ** y' is a syntax error, because UnaryExpression isn't allowed
>>>> before **
>>>>     You must write it as '(-x) ** y'
>>>>     I would expect the production right hand side to be
>>>>         UnaryExpression ** ExponentiationExpression
>>>>     That avoids this strange syntax error and is consistent with the
>>>> pattern followed by productions for lower-precedence operators.
>>>>
>>>> 2. Having UnaryExpression in the right hand side of UpdateExpression
>>>> confuses precedence by going 'backward' to a lower-precedence non-terminal,
>>>> and the only production of UnaryExpression that generates a valid
>>>> argument for '++'/'--' is UnaryExpression => UpdateExpression =>
>>>> LeftHandSideExpression anyway.
>>>>
>>>> I've just finished implementing these rules in the closure-compiler,
>>>> where I had to implement logic to deal with this strange behavior. Is it at
>>>> all possible that these are simply typos in the spec?
>>>>
>>>> Thanks,
>>>> Bradford
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160720/b3dcfc56/attachment.html>