Re: Exponentiation operator precedence

On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller wrote: > I like #4. Normally in a situation like this I would still argue for #1. > #4 is a complicated special case that breaks the normal pattern of operator > precedence elsewhere in the language. The need for ** is not great

Re: Exponentiation operator precedence

Claude Pache wrote: I just wonder why it is important that unary binds tighter? For instance, before I carefully studied the issue of this thread, I have never expected that unary minus binds tighter than binary multiplication operator in expressions like `-2*x` (although it does not matter

Re: Exponentiation operator precedence

Herby Vojčík wrote: Claude Pache wrote: I just wonder why it is important that unary binds tighter? For instance, before I carefully studied the issue of this thread, I have never expected that unary minus binds tighter than binary multiplication operator in expressions like `-2*x`

Re: Exponentiation operator precedence

Because C (B, BCPL, Algol). Too late to change JS where people do tricks such as !-x. No win in risking compat break. /be On Fri, Sep 25, 2015 at 4:18 AM Herby Vojčík wrote: > > > Herby Vojčík wrote: > > > > > > Claude Pache wrote: > >> > >> I just wonder why it is important

Re: Exponentiation operator precedence

One advantage of #4 is that it will make it possible to introduce either #2 or #3 in the future, if we change our minds. This way we can use real world use cases to decide if we should go for #2 or #3. Marius Gundersen On Fri, Sep 25, 2015 at 1:23 AM, Waldemar Horwat wrote:

Re: Exponentiation operator precedence

Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all known programming languages that have exponentiation operators, binds -x^y =

Re: Exponentiation operator precedence

[Apologies for resending, trying to fix formatting of grammar excerpts. /be] Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all

Re: Exponentiation operator precedence

Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be ___ es-discuss mailing list

Re: Exponentiation operator precedence

Even nicer: http://jsbin.com/baquqokujo I hate email. /be Brendan Eich wrote: Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be

Re: Exponentiation operator precedence

I like #4. Normally in a situation like this I would still argue for #1. #4 is a complicated special case that breaks the normal pattern of operator precedence elsewhere in the language. The need for ** is not great enough to justify introducing a new special case for users to learn. However, in

Re: Exponentiation operator precedence

On 24 September 2015 at 17:19, Brendan Eich wrote: > Even nicer: > > http://jsbin.com/baquqokujo > > I hate email. You are holding it wrong. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org

Re: Exponentiation operator precedence

I won't try to guess where the rendering problem is, but see the attached screenshots. This is how I'm seeing your page on my Chrome and Firefox. On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich wrote: > Even nicer: > > http://jsbin.com/baquqokujo > > I hate email. > > /be > >

Re: Exponentiation operator precedence

On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache wrote: > > Le 24 sept. 2015 à 16:11, Brendan Eich a écrit : > > And indeed apart from dot (a special form whose right operand must be a > lexical identifier-name) and square brackets (which isn't an

Re: Exponentiation operator precedence

ct: Re: Exponentiation operator precedence Right. It's confusing because (as opposed to Math), ** is not a superscripting operator whose typography suggests higher precedence than -, and this matters for the sign of the result when exponentiating. Claude, the Math folks won't often need to negate the

Re: Exponentiation operator precedence

Right. It's confusing because (as opposed to Math), ** is not a superscripting operator whose typography suggests higher precedence than -, and this matters for the sign of the result when exponentiating. Claude, the Math folks won't often need to negate the result, but when they do, they'll have

Re: Exponentiation operator precedence

o include > in the language. > > > > *From:* Brendan Eich <brendan.e...@gmail.com> > *Sent:* Sep 24, 2015 13:18 > *To:* Mark S. Miller; Claude Pache > *Cc:* es-discuss > *Subject:* Re: Exponentiation operator precedence > > Right. It's confusing because (as

Re: Exponentiation operator precedence

<d...@domenic.me > <mailto:d...@domenic.me>> wrote: > I object to #4. Disallowing perfectly reasonable math expressions (Claude's > is a good example) makes this operator too surprising to include in the > language. > > > > From: Brendan Eich <brendan

Re: Exponentiation operator precedence

proposal (4)? > > /be > > > On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola <d...@domenic.me> wrote: > >> I object to #4. Disallowing perfectly reasonable math expressions >> (Claude's is a good example) makes this operator too surprising to include >> in the la

Re: Exponentiation operator precedence

My preference is for 2, but I don't have objections to 4. Either works. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

Thanks again to Brendan for taking time to write this up. And to Mark, thanks for reviewing this and expeditiously providing valuable feedback—it's greatly appreciated. Rick On Thu, Sep 24, 2015 at 8:27 AM Mark S. Miller wrote: > I won't try to guess where the rendering

Re: Exponentiation operator precedence

> Le 24 sept. 2015 à 16:11, Brendan Eich a écrit : > > And indeed apart from dot (a special form whose right operand must be a > lexical identifier-name) and square brackets (which isn't an infix operator > per se), unary operators bind tighter than binary in JS as in C

Re: Exponentiation operator precedence

I agree with that completely. This would also become a gotcha. I can see a lot of people down the road thinking -x ** 2 === -x**2, only to find that's not the case. It looks like it should, which will quickly lead to hard to find bugs. I think it's a terrible idea, but that's just my opinion. On

Re: Exponentiation operator precedence

because the right-side-up way to say that is: e - a * c Yeah, I was waiting for someone to point that out, after I hit send. : ) I should spend more time setting up a better examples... ___ es-discuss mailing list es-discuss@mozilla.org

Re: Exponentiation operator precedence

x ** y ** z is easier to read/write than x.pow(y.pow(z)) That might be cherry picking. Trying to make up something a little more complex: a**b * -c**d + e Math.pow(a, b) * -Math.pow(c, d) + e a.pow(b) * -c.pow(d) + e I don't have strong feelings on this issue, but the third

Re: Exponentiation operator precedence

You don't need to be a language guru to know which operation will be performed first, you can (and should) check an operator precedence and associativity table such as MDN's https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence . Knowing operator

Re: Exponentiation operator precedence

On Thu, Aug 27, 2015 at 9:04 AM, Kevin Smith zenpars...@gmail.com wrote: a**b * -c**d + e I don't think people use unary - like this very often. It's nothing to do with exponentiation. You don't see people write: a * -c + e because the right-side-up way to say that is: e - a * c

Re: Exponentiation operator precedence

On 08/27/2015 09:25 AM, Dean Tribble wrote: Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and

Re: Exponentiation operator precedence

Anecdotal evidence via a quick github search https://github.com/search?l=JavaScriptp=1q=Math.pow+language%3AJavaScript+extension%3Ajsref=advsearchtype=Codeutf8=%E2%9C%93 A significant number of the usages are unit tests. Many others are repeats from popular libraries like D3. The most extreme

Re: Re: Exponentiation operator precedence

Long-time esdiscuss lurker; hopefully this perspective is helpful. I think the problem here is that traditional mathematic notation uses visual cues to imply precedence that JS can't take advantage of. When -3 ** 2 is written out on paper, the 2 is very clearly grouped visually with the 3. In

Re: Exponentiation operator precedence

Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and there are as many uses of Math.sin as there are

Re: Exponentiation operator precedence

On Thu, Aug 27, 2015 at 2:58 PM, Alexander Jones a...@weej.com wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the

Re: Exponentiation operator precedence

Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 ===

Re: Exponentiation operator precedence

Don't rely on github searches to turn up representative examples. It doesn't work that well. Here's my educated guess as to how ** will be used. The most common use will be to square numbers. a² a**2 Math.pow(a, 2) a.pow(2) Currently you might write `a * a`, which is kind of

Re: Exponentiation operator precedence

On 08/27/2015 11:20 AM, Ethan Resnick wrote: Long-time esdiscuss lurker; hopefully this perspective is helpful. I think the problem here is that traditional mathematic notation uses visual cues to imply precedence that JS can't take advantage of. When -3 ** 2 is written out on paper, the 2 is

Re: Exponentiation operator precedence

On 08/27/2015 11:58, Alexander Jones wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant

Re: Exponentiation operator precedence

Not to worry, the significant whitespace prospect was (I trust) a warding-off spell. Good of Waldemar to mention Fortress, too. JS, which as source is and will always be minified, indeed requires full-parsing minifiers, so one might naively still entertain the stated prospect. But it's a bad

Re: Exponentiation operator precedence

x ** y ** z is easier to read/write than x.pow(y.pow(z)) On Aug 27, 2015 8:51 AM, Mark S. Miller erig...@google.com wrote: On Wed, Aug 26, 2015 at 6:19 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my

Re: Exponentiation operator precedence

On 8/27/15 at 11:51 PM, niloy.monda...@gmail.com (Niloy Mondal) wrote: x ** y ** z is easier to read/write than x.pow(y.pow(z)) As a language guru, you know which operation will be performed first. As Joe programmer, I don't and I would need to write it as x ** (y ** z). With some

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 1:03 PM, Thomas thomasjamesfos...@bigpond.com wrote: There's still the issue of exponentiation being right-associative. Unless ** becomes an operator which behaves differently as to how it would in a high school maths class, we're at an impasse. I'm not sure I follow.

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 11:09 AM, Mark S. Miller erig...@google.com wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it

Re: Exponentiation operator precedence

On Aug 26, 2015, at 9:09 AM, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either

Re: Exponentiation operator precedence

On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller erig...@google.com wrote: When the costs were minor, it was ok that the benefits were minor. The costs will probably still be minor if we just let Rick look at it and revise the proposal. What has happened here is - upon implementing the feature,

Re: Exponentiation operator precedence

Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, Addition/Subtraction). Who else learned this? There's nothing sacrosanct about binary precedence being generally lower than unary. Consider the property

Re: Exponentiation operator precedence

I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no

Re: Exponentiation operator precedence

There's still the issue of exponentiation being right-associative. Unless ** becomes an operator which behaves differently as to how it would in a high school maths class, we're at an impasse. That said, ^ is usually the operator used for exponentiation outside programming languages when you

Re: Exponentiation operator precedence

Exponentiation is written in conventional mathematics as if it were a postfix unary operator, parameterised by a value written in superscript. IMO this puts it in a whole different class to binary operators where both operands are written equally. I don't see a ** b ** c as a good reflection of

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 2:55 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first

Re: Exponentiation operator precedence

On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will

Re: Exponentiation operator precedence

Alexander Jones schrieb: Exponentiation is written in conventional mathematics as if it were a postfix unary operator, parameterised by a value written in superscript. IMO this puts it in a whole different class to binary operators where both operands are written equally. I don't see a ** b ** c

Re: Exponentiation operator precedence

Le 26 août 2015 à 00:43, Mark S. Miller erig...@google.com a écrit : When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: While I don't have a strong opinion about the cost of the proposed modified grammar, I protest that the cost

Re: Exponentiation operator precedence

I completely agree. My When the costs were minor refers to when we were not yet aware of the conflict. On Wed, Aug 26, 2015 at 12:19 AM, Claude Pache claude.pa...@gmail.com wrote: Le 26 août 2015 à 00:43, Mark S. Miller erig...@google.com a écrit : When the costs were minor, it was ok that

Re: Exponentiation operator precedence

On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my objection is. The yield counter-example is interesting, but yield is an identifier not an operator symbol, and so does not as clearly fall within or shape operator expectations. If someone explains a

Re: Exponentiation operator precedence

Not much, as far as I can tell. Engines do usually lower this, and redo the whole object when the shape changes, or an intrinsic no longer applies. V8 has a MathPow intrinsic, and I believe SpiderMonkey has similar. On Wed, Aug 26, 2015, 23:45 Jordan Harband ljh...@gmail.com wrote: Is there

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 6:19 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my objection is. The yield counter-example is interesting, but yield is an identifier not an operator symbol, and so does not as

Re: Exponentiation operator precedence

Is there also perhaps a potential performance/static analysis benefit in having it be syntax, rather than a builtin function? `Math.pow` can be overwritten, and varies per-realm, but `**` can not and does not. On Wed, Aug 26, 2015 at 8:21 PM, Mark S. Miller erig...@google.com wrote: On Wed,

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,

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

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

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

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

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

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

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 **

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

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.

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?

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

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

Exponentiation operator precedence

In math, -x² is -(x²), not (-x)². But as proposed for JS, -x**2 is (-x)**2. PHP, Python, Haskell, and D side with the traditional algebraic notation, against JS. Here's PHP: $ php -r 'print(-2 ** 2);' -4 Python: -2 ** 2 -4 Haskell: Prelude -2 ^ 2 -4 The D grammar:

Re: Exponentiation operator precedence

On 08/24/2015 17:24, Jason Orendorff wrote: On Mon, Aug 24, 2015 at 5:45 PM, Waldemar Horwat walde...@google.com wrote: Let's not. As I said at the last meeting, making ** bind tighter than unary operators would break x**-2. And making it sometimes tighter and sometimes looser would be too

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com wrote: What you're describing as sometimes tighter and sometimes looser I would call the same precedence. It's even easier to specify than the current proposal: UnaryExpression : PostfixExpression **

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 8:10 PM, Waldemar Horwat walde...@google.com wrote: That has different right and left precedence and is probably the closest to the mathematical intent. Not to quibble, but I do want to understand: UnaryExpression : PostfixExpression ** UnaryExpression

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 3:45 PM, Waldemar Horwat walde...@google.com wrote: On 08/24/2015 10:08, Jason Orendorff wrote: In math, -x² is -(x²), not (-x)². But as proposed for JS, -x**2 is (-x)**2. PHP, Python, Haskell, and D side with the traditional algebraic notation, against JS. Here's

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 5:45 PM, Waldemar Horwat walde...@google.com wrote: Let's not. As I said at the last meeting, making ** bind tighter than unary operators would break x**-2. And making it sometimes tighter and sometimes looser would be too confusing and lead to other opportunities for