Reason for strange ExponentiationExpression & UpdateExpression productions?

[Jordan Harband]

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/99f7e18e/attachment-0001.html>