Reason for strange ExponentiationExpression & UpdateExpression productions?

[Rick Waldron]

The tests for that are here:
https://github.com/tc39/test262/blob/master/test/language/expressions/exponentiation/exp-operator-precedence-update-expression-semantics.js

I'm glad the previous link was helpful—hopefully this will be equally as
useful.

Rick

On Fri, Jul 22, 2016 at 1:04 PM Bradford Smith <bradfordcsmith at google.com>
wrote:

> Thanks! That does make behavior of ** in combination with unary operators
> very clear.
> I've made note of that repo for future reference.
>
> A brief search didn't turn up any test cases that would enlighten me
> regarding why the rules for UpdateExpression are:
>
> UpdateExpression :
>     { ++ | -- } UnaryExpression
>     LeftHandSideExpression { ++ | -- }
>
> You can't increment or decrement anything that isn't a
> LeftHandSideExpression, so why does the syntax rule allow UnaryExpression
> as an argument for update in the prefix case?
>
> Not a critical question, but I am very curious.
>
> Thanks,
> Bradford
>
> On Thu, Jul 21, 2016 at 12:26 PM Rick Waldron <waldron.rick at gmail.com>
> wrote:
>
>> 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/20160725/27c651a4/attachment-0001.html>