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 <[email protected]> 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 <[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
