Exponentiation operator precedence
brendan.eich at gmail.com
Thu Sep 24 20:20:40 UTC 2015
Sez you! :-P
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 **).
Saying "Math!" doesn't overcome this, any more than shouting "typography!"
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
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.
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.
I did find a formula search engine. See
http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1 for a
taste of the hard cases (and false positives, which do not count).
Methinks you protest too much. Where is the common case made hard by
On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola <d at 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.eich at 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 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 to parenthesize. That's the price of the typographic
> shift and the precedence inversion that it suggests to many people.
> On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller <erights at google.com>
>> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache <claude.pache at gmail.com>
>>> Le 24 sept. 2015 à 16:11, Brendan Eich <brendan at mozilla.org> 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 and other
>>> C-derived languages.
>>> 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
>> Before Jason pointed out the discrepancy:
>> * all of us on the committee who were engaged with the proposal
>> * including myself,
>> * all those who reviewed the proposal,
>> * and all those who implemented the proposal
>> 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
>>> multiplication operator in expressions like `-2*x` (although it does not
>>> matter in that case).
>>> without having to parenthesize unduly, but one cannot write
>>> let z = -x ** y;
>>> The user is forced by an early error to write either (-x)**y or -(x**y).
>>> 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`.
>>> 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:
>>> let s2 = - x**2 - y**2 - z**2 + t**2
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss