# Designing an Exponentiation Operator for JavaScript

Update: This proposal now has two open bugs for implementation, on V8 and SpiderMonkey.

In this article, I’ll explore the process of adding syntax to a programming language by going through the process of designing a new JavaScript exponentiation operator, which I’ve submitted to TC39 for consideration in ES7.

In many programming languages, exponentiation is written with a syntactic arithmetic operator expression form; most commonly as `x ** y` (Python, F#, Ruby, Perl, et al.), or `x ^ y` (BASIC, Lua, MATLAB, R, et al.). Other languages including JavaScript or C# rely on built-in objects to provide a function to call: `Math.pow` and `Math.Pow`.

To design an exponentiation operator for JavaScript, it makes sense to borrow an established syntax, this will have impact on both teachability and learnability, as it takes advantage of an existing mental model and definition associated with a visual form. From the two designs described in the previous paragraph I’ve chosen the `**` form because the character `^` is already in use as JavaScript’s bitwise `XOR` operator. The `**` form is complimented by a compound assignment operator form: `**=`. The semantics are defined as matching those of the built-in `Math.pow` function (assuming that it is the original `Math.pow` as defined by Ecma-262).

• 24 = 1 * 2 * 2 * 2 * 2 = 16
• -2-4 = 1 / -2 / -2 / -2 / -2 = 0.0625

In existing and proposed JavaScript forms:

``````Math.pow(2, 4) === 16;
Math.pow(-2, -4) === 0.0625;

2 ** 4 === 16;
-2 ** -4 === 0.0625;

var a = 2;
var b = -2;

a **= 4;
a === 16;

b **= -4;
b === 0.0625;
``````

Before defining a new syntactic form for ES7, we’ll look at the existing arithmentic operator grammar definitions. In ES5 (and ES6) `MultiplicativeExpression` has the highest arithmetic operator precedence after `UnaryExpression` and is followed by `AdditiveExpression` (and so on):

``````MultiplicativeExpression[Yield] :
UnaryExpression[?Yield]
MultiplicativeExpression[?Yield] MultiplicativeOperator UnaryExpression[?Yield]

MultiplicativeOperator : one of
* / %
``````

…Which means that the following two expressions have the same result:

``````-2 * 2 + 1 === -3;
1 + -2 * 2 === -3;
``````

This is because they are evaluated in exactly the same order, despite being written in different order. The order is:

1. unary (`-2`)
2. multiplication (`-2 * 2`)
3. unary (`-4`, the result of step 2)
4. addition (`-4 + 1`, `1 + -4`)

Exponentiation must be evaluated before multiplication and more importantly, the BNF grammar must be written such that the operator’s right-associativity is clearly defined (unlike `MultiplicativeExpression`, which is left-associative). The following invariant illustrates the associativity requirement:

``````a ** b ** c === Math.pow(a, Math.pow(b, c));
``````

A new `ExponentiationExpression` definition will replace the `UnaryExpression` definition in `MultiplicativeExpression`; the change looks like this:

``````ExponentiationExpression :
UnaryExpression[?Yield]
UnaryExpression[?Yield] ** ExponentiationExpression[?Yield]

MultiplicativeExpression[Yield] :
ExponentiationExpression[?Yield]
MultiplicativeExpression[?Yield] MultiplicativeOperator ExponentiationExpression[?Yield]

MultiplicativeOperator : one of
* / %

AssignmentOperator : one of
=
*=
/=
%=
+=
-=
<<=
>>=
>>>=
&=
^=
|=
**=
``````

As of this year, TC39 adopted a 4-stage process for vetting proposed changes to the ECMAScript specification. This model is designed to hopefully facilitate a faster specification release period. I presented this proposal at the last face-to-face meeting as a Stage 0 proposal for ES7 with Stage 1 criteria already complete. Shortly before being presented, and based on the strawman proposal, Erik Arvidsson implemented the operator as an experimental feature in Google’s Traceur Compiler. The proposal is publicly available and progress can be tracked by following the tc39/ecma262 repository.

We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.

• I think you should update your article with your justification here for adding an exponent operator to JavaScript.

• Like const and let, this is another language feature that will only be used in node, until all browser versions that don’t support become extinct in the wild.
Basically never.

• Is exponentiation with powers other than 2 and maybe 10, or exponents other than 2 or 3, actually common outside of specialized domains like scientific computing?

1. I think it’s a good helpful feature. ** sounds good. PHP will get this too (5.6):

2. I liked the article, very well written! Just one thing, there is a \”be\” missing in the following part \”…the BNF grammar must written such that the operator\u2019s right-associativity…\”.

3. Minor nitpicking: doesn’t -2-4 equal -Math.pow(2, -4) = -0.0625? For -2 as the base, you need parentheses: (-2)-4

• I guess formatting broke when posting. Attempt to fix with **:

-2**-4 equals -Math.pow(2, -4) = -0.0625

(-2)**-4 equals Math.pow(-2, -4) = 0.0625

• The grouping operator is meaningless in that example, because the unary expression is already higher than the exponentiation expression.

``// These have the same mathematical // value in JavaScript:(-2) === -2;// These semantics must be // matched by the syntactic // form's semantics: Math.pow((-2), 2) === Math.pow(-2, 2);``
4. You should fix operator precedence, because (-2) ** x != -2 ** x
The latter should equal to -(2 ** x), yelding a different result.
It’s a matter of math, so I would be really confused if the operator behaved in a different way

• I fully agree. I would expect -2**2 to equal -Math.pow(2,2) = -4 since this is how it would be evaluated in maths.
And I think, that’s how the programming languages mentioned in the article are evaluating it, too.

5. It’s very tempting to fix NaN**0 to be NaN while we have the chance here :). Though of course remaining bug-for-bug compatible with Math.pow also has utility.

6. Trying to understand EcmaScript grammar now and your post helps a lot, thanks. I’m wondering why you decided not to introduce ExponentiationOperator the way it’s done for MultiplicativeOperator and instead used the literal `**` in the non-terminal ExponentiationExpression definition?