Reason for strange ExponentiationExpression & UpdateExpression productions?

[Rick Waldron]

Bradford,

Take a look at the tests that I wrote for that syntax, I think they will be
helpful in understand what that syntax actually is:
https://github.com/tc39/test262/blob/master/test/language/expressions/exponentiation/exp-operator-precedence-unary-expression-semantics.js#L34-L66


Rick


On Wed, Jul 20, 2016 at 4:41 PM Bradford Smith <bradfordcsmith at google.com>
wrote:

> 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
>>>>>
>>>>>
>>>>
>> _______________________________________________
> 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/20160721/8e28c2bf/attachment.html>