Reason for strange ExponentiationExpression & UpdateExpression productions?

Bradford Smith bradfordcsmith at google.com
Fri Jul 22 17:04:11 UTC 2016


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/20160722/1230e688/attachment.html>


More information about the es-discuss mailing list