<div dir="ltr"><div>The worry over the meaning of (- x ** y) arises not just due to conventions or inference from typography, but from intuitions based on limited knowledge. As Dave Herman pointed out yesterday, many programmers (most) do not have the full precedence and associativity set memorized. When in doubt, they will rely on precedent in the language, visual cues including weight of operator (two chars vs. one), unary vs. binary. When in more doubt, they'll over-parenthesize.</div><div><br></div><div>The problem case is exactly the user cohort who'll not have enough doubt to over-parenthesize, who will rely on precedent and typographic weight clues, sound or not.</div><div><br></div><div>Mark Miller pointed out how many reviewers missed the problem with the original proposal as predicting likely confusion at scale. If we can avoid any confusion with an error, and force the people who should over-parenthesize to do so, while taxing the Math fans to do it when they must as well, this seems more prudent than just sticking with the Math-trumps-JS precedent and letting wrong results pass silently at runtime.</div><div><br></div>(I see no reason to disallow right-associative chaining. We haven't run head-on into confusion by drafting it the wrong way and getting it to stage 3 :-P.)<div><br></div><div>/be</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 2:05 PM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>Le 24 sept. 2015 à 22:20, Brendan Eich <<a href="mailto:brendan.eich@gmail.com" target="_blank">brendan.eich@gmail.com</a>> a écrit :</div><br><div><div dir="ltr">Sez you! :-P<div><br></div><div>Seriously, the problem you are dismissing implicitly (bad form :-/) is the one we discussed yesterday, which I've stated explicitly twice now: the typography and plain sense of JS-in-itself suggests unary minus binds tighter than any binary connective (including **).</div></div></div></blockquote><div><br></div></span><div><div>It’s more a question of convention than of typography, as in: `x + y * z` or: `x || y && z`.</div><div><br></div><div>There are two conflicting conventions here, not two conflicting typographies. For the set of operators defined in C, the convention of making every unary operator having a higher precedence, does not conflict with the conventions used in math. (It is not clear for me why that convention is important, just that it is a handy uniform rule that works well for some limited set of operators.)</div><div><br></div><div>Note that if you want to disallow `-x**y`, you might want to disallow `x**y**z` (which is imho more confusing), as there is no other right-associative binary operator (except assignment).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>—Claude</div></font></span></div><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Saying "Math!" doesn't overcome this, any more than shouting "typography!" or "JS-in-itself!"</div><div><br></div><div>You don't get to pick a winner just because you root for one team. If you think the operator is worth adding and you concede that the other team's position is tenable because enough people are confused on the committee to predict a wider problem, then you have to consider whether the hardship of mandatory parens in the rare case of negated exponentiation expression is onerous.</div><div><br></div><div>It's not a source of runtime bugs, where test coverage is never good enough. It's a SyntaxError, so (a) Math uber alles people who (b) run into the rare hard case will learn to parenthesize.</div><div><br></div><div>I suspect that many Math-should-prevail types (I am among them in the abstract, prior to engaging with the human factors at play in JS) will want to parenthesize anyway, given the typographic appearance of precedence inversion. I will certainly do it if there's any unary prefixing an exponentiation expression in my code.</div><div><br></div><div>I did find a formula search engine. See <a href="http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1" target="_blank">http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1</a> for a taste of the hard cases (and false positives, which do not count).</div><div><br></div><div>Methinks you protest too much. Where is the common case made hard by proposal (4)?</div><div><br></div><div>/be</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola <span dir="ltr"><<a href="mailto:d@domenic.me" target="_blank">d@domenic.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12.0pt;color:#1f497d">
<div><span style="font-size:14.56px;line-height:normal">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.</span></div>
<div><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12.0pt;color:#1f497d">
 </div>
</div>
<div style="clear:both"><br>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<span style="font-size:11.0pt;font-family:Calibri,Arial,Helvetica,sans-serif"><b>From:</b> Brendan Eich <<a href="mailto:brendan.eich@gmail.com" target="_blank">brendan.eich@gmail.com</a>><br>
<b>Sent:</b> Sep 24, 2015 13:18<br>
<b>To:</b> Mark S. Miller; Claude Pache<br>
<b>Cc:</b> es-discuss<br>
<b>Subject:</b> Re: Exponentiation operator precedence<br>
</span></div>
</div><div><div>
<br type="attribution">
<div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>Claude, the Math folks won't often need to negate the result, but when they do, they'll have to parenthesize. That's the price of the typographic shift and the precedence inversion that it suggests to many people.</div>
<div><br>
</div>
<div>/be</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller <span dir="ltr">
<<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache
<span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div><span>
<blockquote type="cite">
<div>Le 24 sept. 2015 à 16:11, Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>> a écrit :</div>
<br>
<div>
<div bgcolor="#FFFFFF" style="background-color:rgb(255,255,255)">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 and other C-derived languages.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
</span>
<div>Before Jason pointed out the discrepancy:</div>
<div>  * all of us on the committee who were engaged with the proposal</div>
<div>  * including myself,</div>
<div>  * all those who reviewed the proposal, </div>
<div>  * and all those who implemented the proposal </div>
<div>had the opposite naive expectation. That's the point. In the absence of learning about this case specifically, many people will be unpleasantly surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won ;).)</div>
<span>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>multiplication operator in expressions like `-2*x` (although it does not matter in that case).</div>
<span><br>
<blockquote type="cite">
<div>
<div bgcolor="#FFFFFF" style="background-color:rgb(255,255,255)"><br>
without having to parenthesize unduly<span style="font-family:monospace"></span>, but one cannot write<br>
<br>
<big><span style="font-family:monospace">let z = -x ** y;</span></big><br>
<br>
The user is forced by an early error to write either <span style="font-family:monospace">
(-x)**y</span> or <span style="font-family:monospace">-(x**y)</span>.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ with mandatory parentheses, so I don’t expect that many people will be tempted to miswrite it `-x ** n`.</div>
<div><br>
</div>
<div>Making the parentheses mandatory here will be somewhat annoying in perfectly reasonable expressions, where you usually don’t use parentheses in real math notation., like:</div>
<div>```</div>
<div>let s2 =  - x**2 - y**2 - z**2 +  t**2</div>
<div>```</div>
<span><font color="#888888">
<div><br>
</div>
<div>—Claude</div>
<div><br>
</div>
</font></span></div>
<br>
</div>
</blockquote>
</span></div>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>    Cheers,<br>
    --MarkM</div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div></div></div>

</blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div>