It's pretty weird. On Wed, Jul 20, 2016 at 3: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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
