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 <bradfordcsm...@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 <ljh...@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 < >> bradfordcsm...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
