Re: Exponentiation operator precedence
Le 25 août 2015 à 19:25, Mark S. Miller erig...@google.com a écrit : It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). Unless I missed something, it *is* right-associative. —Claude On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com mailto:erig...@google.com wrote: It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com mailto:isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com mailto:claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com wrote: It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
I'm a python user and I dislike using **, it just becomes rather noisy. Expressing formulas in text based programming languages has always been kind of a drag. On the other hand, often the mathematical expression of a formula would be quite inefficient because they lack the ability to keep temporary results in some variable. Picking a formula apart to isolate those temporaries the expressiveness vanishes naturally. On Tue, Aug 25, 2015 at 7:25 PM, Mark S. Miller erig...@google.com wrote: It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com wrote: It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ 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
Re: Exponentiation operator precedence
Sorry. I just has another look at your proposed grammar and you are correct. On Tue, Aug 25, 2015 at 10:54 AM, Claude Pache claude.pa...@gmail.com wrote: Le 25 août 2015 à 19:25, Mark S. Miller erig...@google.com a écrit : It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). Unless I missed something, it *is* right-associative. —Claude On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com wrote: It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ 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
Re: Exponentiation operator precedence
This may be of some relevance: https://en.wikipedia.org/wiki/Order_of_operations#Special_cases Exponentiation is clearly exponentially more complicated in terms of order of operations and precedence than other operators if the desire is to follow 'standard maths'. Otherwise, making Exponentiation behave differently in JavaScript to how it does elsewhere is going to be a constant source of bugs and needing parentheses just to get the desire behaviour negates the whole point of making it an operator vs a function. Thomas On 26 Aug 2015, at 1:49 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 25, 2015, at 8:11 AM, Mark S. Miller wrote: I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime behavior that *sometimes* violates expectations. I was all for adding ** to the language when it did not have these problems. But it does. The minor convenience it adds is not worth these costs. By contrast, no one is confused about the parsing of calls to Math.pow. When in doubt, leave it out. I've had the same reaction to this recent thread. It seems like the functional form (Math.pow) is a much less confusing formulation for use in JS expressions. It's interesting to note that while early algebraic languages such as FORTRAN, Algol 60, BASIC, PL/I all had exponentiation operators the next couple generations of similar languages including Pascal, C, C++, Java, and C# do not. Each of those languages could have had an exponentiation operator but choose to exclude it. The utility of an exponentiation operation may simply not be worth the complexity and potential for confusion it introduces into a language with a rich set of operators. Allen ___ 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
Re: Exponentiation operator precedence
I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime behavior that *sometimes* violates expectations. I was all for adding ** to the language when it did not have these problems. But it does. The minor convenience it adds is not worth these costs. By contrast, no one is confused about the parsing of calls to Math.pow. When in doubt, leave it out. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
So far, I like the idea of exponentiation having identical precedence to unary `+`/`-`, and lower than the increment operators. That sounds like it should work pretty well. ``` x ** y // x^y -x ** y // -(x^y) x ** -y // x^(-y) ++x ** y === (++x) ** y x++ ** y === (x++) ** y x ** ++y === x ** (++y) x ** y++ === x ** (y++) ``` On Tue, Aug 25, 2015, 12:17 Thomas thomasjamesfos...@bigpond.com wrote: This may be of some relevance: https://en.wikipedia.org/wiki/Order_of_operations#Special_cases Exponentiation is clearly exponentially more complicated in terms of order of operations and precedence than other operators if the desire is to follow 'standard maths'. Otherwise, making Exponentiation behave differently in JavaScript to how it does elsewhere is going to be a constant source of bugs and needing parentheses just to get the desire behaviour negates the whole point of making it an operator vs a function. Thomas On 26 Aug 2015, at 1:49 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 25, 2015, at 8:11 AM, Mark S. Miller wrote: I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime behavior that *sometimes* violates expectations. I was all for adding ** to the language when it did not have these problems. But it does. The minor convenience it adds is not worth these costs. By contrast, no one is confused about the parsing of calls to Math.pow. When in doubt, leave it out. I've had the same reaction to this recent thread. It seems like the functional form (Math.pow) is a much less confusing formulation for use in JS expressions. It's interesting to note that while early algebraic languages such as FORTRAN, Algol 60, BASIC, PL/I all had exponentiation operators the next couple generations of similar languages including Pascal, C, C++, Java, and C# do not. Each of those languages could have had an exponentiation operator but choose to exclude it. The utility of an exponentiation operation may simply not be worth the complexity and potential for confusion it introduces into a language with a rich set of operators. Allen ___ 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
Re: Exponentiation operator precedence
It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). That way, we have the following expected behaviour: * in/decrement operators bind most tightly; * unary and exponentiation operators are applied from right to left. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Tue, Aug 25, 2015 at 11:12 AM Mark S. Miller erig...@google.com wrote: I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime behavior that *sometimes* violates expectations. I was all for adding ** to the language when it did not have these problems. But it does. The minor convenience it adds is not worth these costs. By contrast, no one is confused about the parsing of calls to Math.pow. Math.pow has exactly the same semantics as the _current_ ** . I'd like the opportunity to work with Claude and Brian to resolve the grammar issue before just tossing it out. Thanks. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Le 25 août 2015 à 03:22, Jason Orendorff jason.orendo...@gmail.com a écrit : On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com P.S. Admittedly it might be a good idea to rename UnaryExpression if we put a binary operator in there. -j RightAssociativeExpression? —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On 08/25/2015 09:38, Claude Pache wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no LineTerminator here] -- ++ LeftHandSideExpression -- LeftHandSideExpression ``` And define UnaryExpression as: ``` UnaryExpression: IncrementExpression delete UnaryExpression void UnaryExpression typeof UnaryExpression ++ UnaryExpression + UnaryExpression -- UnaryExpression - UnaryExpression ~ UnaryExpression ! UnaryExpression IncrementExpression ** UnaryExpression ``` The above is not a valid grammar. For example, parsing ++x leads to a reduce-reduce conflict, where the ++ can come from either a UnaryExpression or an IncrementExpression. where the following production (which exists only to avoid to confusingly interpret, e.g., `++x++` as `+ +x++`): That makes no sense. ++ is a lexical token. The lexer always greedily bites off the largest token it can find, even if that leads to a parser error later. The parser does not backtrack into the lexer to look for alternate lexings. For example, x + y; is a syntax error because it's greedily lexed as: x ++ ++ + y; The parser does not backtrack into the lexer to look for other possible lexings such as: x ++ + ++ y; ``` UnaryExpression: ++ UnaryExpression -- UnaryExpression ``` yields a static SyntaxError (or a static ReferenceError if we want to be 100% compatible ES2015). This is a problem. It makes ++x into a static SyntaxError because x is a UnaryExpression. If you got rid of these two ++ and -- productions in UnaryExpression, that would solve that problem (and I think make the grammar valid). Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: Why do we need ** ? What great benefit does it provide? If nothing compelling, then this proposal has lost consensus. On Tue, Aug 25, 2015 at 3:30 PM, Claude Pache claude.pa...@gmail.com wrote: Le 25 août 2015 à 03:22, Jason Orendorff jason.orendo...@gmail.com a écrit : On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com P.S. Admittedly it might be a good idea to rename UnaryExpression if we put a binary operator in there. -j RightAssociativeExpression? —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Finding elements that are hidden due to overflow: hidden
Hi, Looks like at the moment DOM does not expose any properties that signify whether an element has become hidden due to an *overflow: hidden *on their parent element. Any chance of adding this feature to DOM? -- Best regards, Behrang Saeedzadeh ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
