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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]> 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 <
>>> [email protected]> 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 <[email protected]>
>>>> 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 <
>>>>> [email protected]> 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
>>>>>> [email protected]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
