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
