<p>C does not have an exponentiation operator, so that freestanding implementations that lack the math libraries could lack exponentiation as a whole, and still be permissible by the C standard. As a result, we have a <code>pow()</code> function for exponentiation and <code>^</code> for XOR, which any reasonable system has.</p>
<p>But many languages, even those without a concept of freestanding implementations that lack most of the standard library, followed in the footsteps of C, and as a result, lack an exponentiation operator, a function which <code>^</code> would intuitively have.</p>
<p>Dropping support for systems that lack exponentiation capabilities, what syntax choices do I have to implement an exponentiation operator?</p>

<syntax><operators><math>
What syntax could be used to implement both an exponentiation operator and XOR?
CC BY-SA 4.0
2023-07-03T21:40:11.287Z
The question title asks about implementation (in which case they are unrelated, and just two different questions, but both are relatively trivial). But it seems from the question body that you want to know about syntax choices, not how to implement these operators. I'm not sure what *"But many languages, even those without a concept of freestanding implementations that lack most of the standard library"* means.
kaya3
CC BY-SA 4.0
2023-07-03T21:42:26.883Z
@kaya3-supportthestrike C has this concept of 'freestanding implementation' which basically means a C implementation that lacks most of the standard library.
CPlus
CC BY-SA 4.0
2023-07-03T21:43:26.137Z
OK. Well, I don't see what that has to do with what the syntax choices for exponentiation are. It seems to me that the question could be written simply as, "what syntax options are there for exponentiation, assuming that `^` is reserved for the XOR operator?"
kaya3
CC BY-SA 4.0
2023-07-03T22:17:02.793Z
@kaya3-supportthestrike Explaining the rationale for many languages **not** having an exponentiation operator. That's all.
CPlus
CC BY-SA 4.0
2023-07-04T00:31:08.747Z
See also [What syntax could infix method calls use?](https://langdev.stackexchange.com/questions/1178/what-syntax-could-infix-method-calls-use).
BoppreH
<h1>Demote xor</h1>
<p>Unless you're in C or a similarly low-level language, you're not going to be doing a lot of bit-level manipulation. So the bitwise operations really don't need to be using up those juicy one-character infix symbols that we have a very limited supply of. In a high-level language, use <code>^</code> for the common case of exponentiation, and supply bitwise-xor (and the other bitwise operations, for that matter) as a named function or an operator with a longer name.</p>
<ul>
<li>Haskell supplies <a href="https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Bits.html#v:xor" rel="nofollow noreferrer"><code>xor</code></a> as a standard function, not an operator. Haskell also demotes the other bitwise operators to have longer names (<code>.&amp;.</code> and <code>.|.</code>), leaving <code>&amp;</code> available for a higher-order function, <code>|</code> available as syntax, and <code>^</code> for exponentiation.</li>
<li>Julia goes even further, relegating bitwise-xor to the Unicode symbol <a href="https://docs.julialang.org/en/v1/manual/mathematical-operations/#Bitwise-Operators" rel="nofollow noreferrer"><code>⊻</code></a> (with the function <code>xor</code> as an alias), and using <code>^</code> for exponentiation.</li>
</ul>

CC BY-SA 4.0
2023-07-04T00:16:37.897Z
2023-07-05T21:57:19.283Z
2023-07-05T21:57:19.283Z
Silvio Mayolo
CC BY-SA 4.0
2023-07-04T00:27:12.083Z
[As someone who uses a lot of xor's](https://github.com/boppreh/aes/blob/master/aes.py), I have to agree. If the problem calls for xor, the user is a programmer and will know how to find it.
BoppreH
CC BY-SA 4.0
2023-07-04T02:09:39.340Z
I use bitwise arithmetic all the time.
CPlus
CC BY-SA 4.0
2023-07-04T02:31:10.513Z
I, too, use bitwise arithmetic quite a bit even in high-level languages. For example, it's a convenient way to make a map key out of two small integers in Javascript, where you cannot define custom hashable types.
kaya3
CC BY-SA 4.0
2023-07-04T08:30:21.110Z
Lua solves this by using `a ~ b` for XOR and `~a` for negation, which is intuitive since negation is just `0 ~ a`.
Luatic
CC BY-SA 4.0
2023-07-04T15:15:04.300Z
@Luatic by negation do you mean bitwise inversion?  For two's complement numbers producing a negative number from a positive one would require one more step.
Mark Ransom
CC BY-SA 4.0
2023-07-04T15:15:53.807Z
@MarkRansom Yes, unary `~` in Lua performs bitwise negation, not arithmetic negation (which uses `-` like most mainstream languages)
Silvio Mayolo
CC BY-SA 4.0
2023-07-04T15:17:40.860Z
@SilvioMayolo my point is that calling that operation "negation" is confusing.
Mark Ransom
CC BY-SA 4.0
2023-07-05T06:54:23.490Z
@Luatic that's clever. Go uses `a ^ b` for XOR and `^a` for complementation. But `~` is more intuitive
phuclv
CC BY-SA 4.0
2023-07-05T14:40:57.513Z
In my experience, bit-twiddling is very rarely needed in general application programming. It's mostly either 1) in specialised domains (such as hardware interfacing or bitmapped images), 2) working around language inefficiencies or restrictions, or 3) done by lazy or unimaginative programmers… IMHO there's little excuse for 3; 2 shouldn't apply since we're talking about designing a new language; and 1 shouldn't justify built-in operators if the language syntax allows a standard library function to do it neatly (such as with an infix function, as e.g. Kotlin does).
gidds
CC BY-SA 4.0
2023-07-05T21:07:23.943Z
@Luatic Shouldn't that be `(-1) ~ a` for bitwise negation?
James Wood
CC BY-SA 4.0
2023-07-05T21:15:07.713Z
@JamesWood you're right, `0 ~ a` would of course be just `a`... each bit needs to be XORed with `1` to flip it, thus you need `-1` (or equivalently `0xFF...FF`).
Luatic
CC BY-SA 4.0
2023-07-05T23:04:19.737Z
@Luatic Using `~` as a binary operator for XOR is **brilliant**! You should post that as an answer.
CPlus
CC BY-SA 4.0
2023-07-05T23:06:16.050Z
@gidds My [octree code](https://codereview.stackexchange.com/q/282520/264812) uses tons of bitwise arithmetic. Upon revising it, it will use even more.
CPlus
<p>I think most of the problem comes from functions being in the form <code>op(a, b)</code>, which is verbose and doesn't read well when expressions get complicated.</p>
<h3>So why not use the word <code>pow</code>, but as an infix operator?</h3>
<p>Most of Python's boolean operators are words:</p>
<pre class="lang-python prettyprint-override"><code>if a or b and not c:
    pass
</code></pre>
<p><em>(also in C/C++ with the right flags, but you'll get yelled at)</em></p>
<p>And Haskell has a feature where arbitrary functions can be made infix by wrapping them in backticks. You can use it for either <code>pow</code>, <code>xor</code>, or both:</p>
<pre class="lang-haskell prettyprint-override"><code>2 `pow` 3
2 `xor` 3
</code></pre>
<p>It's fairly annoying if the operator is frequently used (e.g., xor in cryptography), but the readability is very good and mistakes are unlikely.</p>
<p>Of course, you can pick other signifiers instead of double backticks:</p>
<pre><code>2 \pow 3
2 @pow 3
2 $pow 3
2 `pow 3
</code></pre>
<p>Or, if your data model and syntax allows it, as a method on number types, which has the same order as an infix operator:</p>
<pre><code>2.pow(3)
</code></pre>

CC BY-SA 4.0
2023-07-03T23:23:24.090Z
2023-07-03T23:42:33.047Z
2023-07-03T23:42:33.047Z
BoppreH
CC BY-SA 4.0
2023-07-03T23:32:53.673Z
There's precedent for infix "word" operators even in languages without custom operator names, e.g., Pascal's `div` and `mod` for integer division.
dan04
CC BY-SA 4.0
2023-07-03T23:40:03.440Z
@dan04 Right, I forgot about that. Python is another obvious example. I'll edit the answer, thanks.
BoppreH
CC BY-SA 4.0
2023-07-05T14:22:43.747Z
And languages such as Scala and Kotlin allow infix function calls.
gidds
<h1>Double star</h1>
<p>Many languages have a <code>**</code> operator for exponentiation. This is reasonably intuitive, as exponentiation is just the <a href="https://en.wikipedia.org/wiki/Hyperoperation" rel="noreferrer">hyperoperation</a> after multiplication.</p>
<h1><code>^</code> for floating-point only</h1>
<p>Floating point types do not have bitwise operators, so the <code>^</code> operator could mean exponentiation if the operands are floating-point, but still mean XOR if the operands are integers. This could be implemented the same way as <code>pow()</code> as the function is already for floating-point only, as there is <a href="https://stackoverflow.com/questions/101439/the-most-efficient-way-to-implement-an-integer-based-power-function-powint-int#comment737605_101439">no <code>pow()</code> for integers in C</a>.</p>

CC BY-SA 4.0
2023-07-03T21:33:28.457Z
2023-07-03T21:33:28.457Z
CPlus
CC BY-SA 4.0
2023-07-03T21:47:58.960Z
`^^` could also work, no?
Adám
CC BY-SA 4.0
2023-07-03T22:02:23.000Z
So `2.0^3` is 8, but `2^3` is 1?  That would *easily* cause confusion.
dan04
CC BY-SA 4.0
2023-07-03T23:12:37.470Z
+1 for the double star, -1 for the floating-point-only solution. Is it even implemented anywhere?
BoppreH
CC BY-SA 4.0
2023-07-03T23:28:12.653Z
Haskell uses [`^`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-94-) for non-negative integral power, [`^^`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-94--94-) for possibly-negative integral power, and [`**`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-42--42-) for floating-point power. Btw I agree that overloading the same operator `^` for integer XOR and floating power is probably not a good idea.
Bubbler
CC BY-SA 4.0
2023-07-05T00:51:18.010Z
python3 does ** and i like python3 so, there is my very biased comment why i believe this is a good answer
Sidharth Ghoshal
<p>** is fairly common. Speaking personally, I strongly dislike &quot;identifiers that parse like operators&quot; of which the most notorious is Pascal's inline mod. Unicode is best avoided at least in a base language (i.e. it would be a nice thing to be able to construct custom Unicode operators on a project- or site-specific basis).</p>
<p>I think the best solution would be to make it strongly depend on the type of the operands, i.e. to distinguish between bytes etc. which can be xored, anded etc. and integers which can be added and multiplied. In fact I came across this a year or so ago written as (in part) a criticism of APL's odd parsing:</p>
<blockquote>
<p>...one need only deal with operators that have the same kind of operand, i.e. that have the same domains. For example, A + B &gt; C must imply comparing A + B with C, because A + B gives a numerical sresult whereas B &gt; C gives a logical result and one cannot add a number and a logical value, despite APL and PL/1 pretending that one can. There is, therefore, no need to establish relative precedences for + and &gt;. P.A.Samet, UCL, circa 1975.</p>
</blockquote>
<p><a href="https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380050310" rel="nofollow noreferrer">https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380050310</a></p>
<p>My holy grail is a moderately efficient parser which can handle the ambiguities relating to monadic/dyadic ^ (dereference, xor, exponentiation) and monadic ! (negation, factorial) as well as Smalltalk-style keywords.</p>
<p>Looking back through some notes, ! is an interesting case particularly if we would also like it to be a dyadic operator to suit e.g. APL's combination operator.</p>
<pre><code>x!       x factorial
!y       y negated, only valid if y is a boolean
!!z      Integer z converted to a boolean
a ! b   Number of combinations of b taken in groups of a
a! b    Can't be postfix factorial, lacks a dyadic operator
a !b    Can't be prefix negation, and b not a boolean
a !!b   Invalid, lacks a dyadic operator
a! ! b  Number of combinations of b taken in groups of a! (a factorial)
</code></pre>
<p>What I concluded from that type of exercise is that a character could be used for a fairly wide mix of operators including type-dependent local definitions, but that the situation could be improved enormously if there were an initial (i.e. project level) declaration of what characters and character sequences should be considered valid operators with association rules etc. and that definitions were not allowed to vary this.</p>

CC BY-SA 4.0
2023-07-04T06:51:26.710Z
2023-07-07T07:24:14.977Z
2023-07-07T07:24:14.977Z
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-04T23:34:15.203Z
Is your proposal to have no types that support both bitwise and arithmetic operations?  So [bithacks](https://catonmat.net/low-level-bit-hacks) such as clearing the lowest set bit (`x &= x-1` in C) would need casts to different types for the `-1` and the `&`?
Peter Cordes
CC BY-SA 4.0
2023-07-05T08:04:48.590Z
Well, it's just a "thought experiment" at the moment but I think it's a question of favouring the most common usage for each operation. In addition, once the parser has chosen the correct operation the optimiser should be able to eliminate any overhead introduced by casting.
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-05T09:44:08.353Z
`**` doesn't work well particularly well for C or C++, because `*` as a unary operator (dereference) can be needed multiple times (unlike unary `+` or `-`).  But it is indeed common in languages without a unary `*` operator.
Toby Speight
CC BY-SA 4.0
2023-07-05T13:45:48.253Z
I can assure you that C is the last thing on my mind :-) Besides, which, successive dereferences work perfectly well if the referent is itself a pointer: the real problem in this area is languages like Object Pascal (as implemented by Delphi) which allow the unary dereference operator (^ in this case) to be omitted under certain circumstances.
Mark Morgan Lloyd
<h2>Unicode</h2>
<p>See for examples:</p>
<ul>
<li><a href="https://en.wikipedia.org/wiki/List_of_logic_symbols" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/List_of_logic_symbols</a></li>
<li><a href="https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode</a></li>
</ul>
<h1>Powers</h1>
<h3>Superscript for powers</h3>
<p>2<sup>3</sup></p>
<p>Downsides:</p>
<ul>
<li><p>It seems this has to be <a href="https://stackoverflow.com/questions/76616411/is-there-a-unicode-combiner-akin-to-a-superscript-style">implemented as a style</a>. There is no simple unicode combiner trick.</p>
</li>
<li><p>That gives it the same risks as giving semantic meaning colour or italics but you could if you were willing to accept &lt;sup&gt; in an ASCII version of your code.</p>
</li>
<li><p>It could also get messy if you want nested powers like 2<sup>3<sup>4</sup></sup></p>
</li>
</ul>
<p>Based on that I have to prefer the simple obvious and (not wrong) suggestion of:</p>
<h3>Double star</h3>
<p>As suggested in <a href="https://langdev.stackexchange.com/a/1960/285">https://langdev.stackexchange.com/a/1960/285</a></p>
<blockquote>
<p>Many languages have a ** operator for exponentiation. This is  reasonably intuitive, as exponentiation is just the hyperoperation after multiplication.</p>
</blockquote>
<p>Though there is no reason a clever IDE couldn't render that as a superscript I suppose but it might cause some <em>cognitive stress</em>.</p>
<h2>Prior art</h2>
<p>As helpfully pointed out in response to <a href="https://math.stackexchange.com/questions/4731159/symbols-for-exponentiation?noredirect=1#comment10028651_4731159">my question</a> that wikipedia mentions:</p>
<ul>
<li>x ↑ y: Algol Reference language, Commodore BASIC, TRS-80 LevelII/III BASIC.[45][46]</li>
<li>x ^^ y: Haskell (for fractional base, integer exponents), D.</li>
<li>x⋆y: APL.</li>
</ul>
<p>The up arrow has other meanings including the next <a href="https://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation" rel="nofollow noreferrer">hyperoperation</a> up from exponentation.</p>
<p>APLs use of a single star is bound to cause confusion for users thinking in ASCII. APL uses × for multiplication.</p>
<h1>Logic</h1>
<h3>veebar or oplus for xor</h3>
<p>⊻
⊕</p>
<hr />
<h2>consider IDE support</h2>
<p>You could have your IDE do things like automagically convert <code>**</code> to superscript and <code>v_</code> to ⊻ say.
It would not surprise me if there are relative common key shortcuts for these already and they are just not more widely known.</p>
<p>It is obligatory to remember <a href="https://en.wikipedia.org/wiki/Digraphs_and_trigraphs" rel="nofollow noreferrer">trigraphs</a> at this point and note that they have <a href="https://stackoverflow.com/questions/27601706/c17-why-not-remove-digraphs-along-with-trigraphs">only recently</a> been purged from languages like C++.</p>
<p>Off topic but it would be nice to be able to standardise on something like:</p>
<ul>
<li><a href="http://terathon.com/blog/a-mathematical-keyboard-layout/" rel="nofollow noreferrer">http://terathon.com/blog/a-mathematical-keyboard-layout/</a></li>
</ul>
<p>Defining a &quot;meta key&quot; for maths and one key for each common symbol so you don't have to type the Unicode in full.</p>

CC BY-SA 4.0
2023-07-03T23:03:37.477Z
2023-07-05T20:18:47.703Z
2023-07-05T20:18:47.703Z
Bruce Adams
CC BY-SA 4.0
2023-07-04T10:32:25.963Z
How do you actually want to represent the superscript in the source code, assuming it's still plain text? [With other Unicode](https://en.wikipedia.org/wiki/Superscripts_and_Subscripts_%28Unicode_block%29)? Or with actual HTML tag text?
Karl Knechtel
CC BY-SA 4.0
2023-07-04T11:24:06.250Z
That is a good question - see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts . Superscripts should be a style but in unicode they seem to be hardcoded.
Bruce Adams
CC BY-SA 4.0
2023-07-04T11:52:01.100Z
I've asked it https://graphicdesign.stackexchange.com/questions/161520/is-there-a-unicode-combiner-akin-to-a-superscript-style
Bruce Adams
CC BY-SA 4.0
2023-07-05T19:56:20.583Z
Based on https://stackoverflow.com/questions/76616411/is-there-a-unicode-combiner-akin-to-a-superscript-style superscript has to be done as a style / rich text not as pure unicode
Bruce Adams
CC BY-SA 4.0
2023-07-05T19:58:43.433Z
There are superscript digit symbols, but that doesn't get you arbitrary expressions for exponents, nor nested exponents.
Karl Knechtel
<p>Lua solves this by using <code>x ~ y</code> for XOR.</p>
<p>When applied to floats which do not have an integer representation, it throws an error.</p>
<p>This is reasonably intuitive, since Lua uses <code>~x</code> for bitwise negation (which is pretty common since the C days), and bitwise negation is just a special case of XOR (<code>~x == (~0) ~ x</code>). This also avoids having to introduce a new operator symbol.</p>
<p>(converted from a comment to an answer)</p>
<hr />
<p>Other, more obscure ASCII sequences that come to mind are:</p>
<ul>
<li><code>&lt;&gt;</code>, since XOR can be seen as a bitwise antivalence (downside: many programming languages use this for <code>~=</code> / <code>!=</code>)</li>
<li><code>(+)</code>, since XOR can be seen as a bitwise addition mod 2, which is usually notated as &quot;oplus&quot;</li>
</ul>

CC BY-SA 4.0
2023-07-06T09:32:42.443Z
2023-07-06T09:40:59.683Z
2023-07-06T09:40:59.683Z
Luatic
CC BY-SA 4.0
2023-07-06T09:54:49.057Z
Can it also implement an exponentian operator?
Starship
CC BY-SA 4.0
2023-07-06T09:57:29.940Z
@Starship-OnStrike not sure what you're asking, but Lua uses `^` for exponentiation.
Luatic
CC BY-SA 4.0
2023-07-06T09:58:06.753Z
Then I suppose thats a yes, sorry for the stupid question
Starship
# What syntax could be used to implement both an exponentiation operator and XOR?
Posted by: username_0 on 2023-07-03
C does not have an exponentiation operator, so that freestanding implementations that lack the math libraries could lack exponentiation as a whole, and still be permissible by the C standard. As a result, we have a `pow()` function for exponentiation and `^` for XOR, which any reasonable system has.

But many languages, even those without a concept of freestanding implementations that lack most of the standard library, followed in the footsteps of C, and as a result, lack an exponentiation operator, a function which `^` would intuitively have.

Dropping support for systems that lack exponentiation capabilities, what syntax choices do I have to implement an exponentiation operator?
**Tags:** syntax operators math
> **Comments:**
> **username_1**: The question title asks about implementation (in which case they are unrelated, and just two different questions, but both are relatively trivial). But it seems from the question body that you want to know about syntax choices, not how to implement these operators. I'm not sure what *"But many languages, even those without a concept of freestanding implementations that lack most of the standard library"* means.  
> **username_0**: @kaya3-supportthestrike C has this concept of 'freestanding implementation' which basically means a C implementation that lacks most of the standard library.  
> **username_1**: OK. Well, I don't see what that has to do with what the syntax choices for exponentiation are. It seems to me that the question could be written simply as, "what syntax options are there for exponentiation, assuming that `^` is reserved for the XOR operator?"  
> **username_0**: @kaya3-supportthestrike Explaining the rationale for many languages **not** having an exponentiation operator. That's all.  
> **username_2**: See also [What syntax could infix method calls use?](https://langdev.stackexchange.com/questions/1178/what-syntax-could-infix-method-calls-use).  
---
## 6 answers
### Answer by username_4 on 2023-07-06. Score: 7 | Accepted answer
Lua solves this by using `x ~ y` for XOR.

When applied to floats which do not have an integer representation, it throws an error.

This is reasonably intuitive, since Lua uses `~x` for bitwise negation (which is pretty common since the C days), and bitwise negation is just a special case of XOR (`~x == (~0) ~ x`). This also avoids having to introduce a new operator symbol.

(converted from a comment to an answer)

---

Other, more obscure ASCII sequences that come to mind are:

* `<>`, since XOR can be seen as a bitwise antivalence (downside: many programming languages use this for `~=` / `!=`)
* `(+)`, since XOR can be seen as a bitwise addition mod 2, which is usually notated as "oplus"
> **Comments:**
> **username_18** (2023-07-06): Can it also implement an exponentian operator?  
> **username_4** (2023-07-06): @Starship-OnStrike not sure what you're asking, but Lua uses `^` for exponentiation.  
> **username_18** (2023-07-06): Then I suppose thats a yes, sorry for the stupid question  
---
### Answer by username_3 on 2023-07-04. Score: 19
# Demote xor

Unless you're in C or a similarly low-level language, you're not going to be doing a lot of bit-level manipulation. So the bitwise operations really don't need to be using up those juicy one-character infix symbols that we have a very limited supply of. In a high-level language, use `^` for the common case of exponentiation, and supply bitwise-xor (and the other bitwise operations, for that matter) as a named function or an operator with a longer name.

* Haskell supplies [`xor`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Bits.html#v:xor) as a standard function, not an operator. Haskell also demotes the other bitwise operators to have longer names (`.&.` and `.|.`), leaving `&` available for a higher-order function, `|` available as syntax, and `^` for exponentiation.
* Julia goes even further, relegating bitwise-xor to the Unicode symbol [`⊻`](https://docs.julialang.org/en/v1/manual/mathematical-operations/#Bitwise-Operators) (with the function `xor` as an alias), and using `^` for exponentiation.
> **Comments:**
> **username_2** (2023-07-04): [As someone who uses a lot of xor's](https://github.com/boppreh/aes/blob/master/aes.py), I have to agree. If the problem calls for xor, the user is a programmer and will know how to find it.  
> **username_0** (2023-07-04): I use bitwise arithmetic all the time.  
> **username_1** (2023-07-04): I, too, use bitwise arithmetic quite a bit even in high-level languages. For example, it's a convenient way to make a map key out of two small integers in Javascript, where you cannot define custom hashable types.  
> **username_4** (2023-07-04): Lua solves this by using `a ~ b` for XOR and `~a` for negation, which is intuitive since negation is just `0 ~ a`.  
> **username_5** (2023-07-04): @Luatic by negation do you mean bitwise inversion?  For two's complement numbers producing a negative number from a positive one would require one more step.  
> **username_3** (2023-07-04): @MarkRansom Yes, unary `~` in Lua performs bitwise negation, not arithmetic negation (which uses `-` like most mainstream languages)  
> **username_5** (2023-07-04): @SilvioMayolo my point is that calling that operation "negation" is confusing.  
> **username_6** (2023-07-05): @Luatic that's clever. Go uses `a ^ b` for XOR and `^a` for complementation. But `~` is more intuitive  
> **username_7** (2023-07-05): In my experience, bit-twiddling is very rarely needed in general application programming. It's mostly either 1) in specialised domains (such as hardware interfacing or bitmapped images), 2) working around language inefficiencies or restrictions, or 3) done by lazy or unimaginative programmers… IMHO there's little excuse for 3; 2 shouldn't apply since we're talking about designing a new language; and 1 shouldn't justify built-in operators if the language syntax allows a standard library function to do it neatly (such as with an infix function, as e.g. Kotlin does).  
> **username_8** (2023-07-05): @Luatic Shouldn't that be `(-1) ~ a` for bitwise negation?  
> **username_4** (2023-07-05): @JamesWood you're right, `0 ~ a` would of course be just `a`... each bit needs to be XORed with `1` to flip it, thus you need `-1` (or equivalently `0xFF...FF`).  
> **username_0** (2023-07-05): @Luatic Using `~` as a binary operator for XOR is **brilliant**! You should post that as an answer.  
> **username_0** (2023-07-05): @gidds My [octree code](https://codereview.stackexchange.com/q/282520/264812) uses tons of bitwise arithmetic. Upon revising it, it will use even more.  
---
### Answer by username_2 on 2023-07-03. Score: 16
I think most of the problem comes from functions being in the form op(a, b), which is verbose and doesn't read well when expressions get complicated.
So why not use the word pow, but as an infix operator?
Most of Python's boolean operators are words:
if a or b and not c:
    pass

(also in C/C++ with the right flags, but you'll get yelled at)
And Haskell has a feature where arbitrary functions can be made infix by wrapping them in backticks. You can use it for either pow, xor, or both:
2 `pow` 3
2 `xor` 3

It's fairly annoying if the operator is frequently used (e.g., xor in cryptography), but the readability is very good and mistakes are unlikely.
Of course, you can pick other signifiers instead of double backticks:
2 \pow 3
2 @pow 3
2 $pow 3
2 `pow 3

Or, if your data model and syntax allows it, as a method on number types, which has the same order as an infix operator:
2.pow(3)
> **Comments:**
> **username_9** (2023-07-03): There's precedent for infix "word" operators even in languages without custom operator names, e.g., Pascal's `div` and `mod` for integer division.  
> **username_2** (2023-07-03): @dan04 Right, I forgot about that. Python is another obvious example. I'll edit the answer, thanks.  
> **username_7** (2023-07-05): And languages such as Scala and Kotlin allow infix function calls.  
---
### Answer by username_0 on 2023-07-03. Score: 16
# Double star

Many languages have a `**` operator for exponentiation. This is reasonably intuitive, as exponentiation is just the [hyperoperation](https://en.wikipedia.org/wiki/Hyperoperation) after multiplication.

# `^` for floating-point only

Floating point types do not have bitwise operators, so the `^` operator could mean exponentiation if the operands are floating-point, but still mean XOR if the operands are integers. This could be implemented the same way as `pow()` as the function is already for floating-point only, as there is [no `pow()` for integers in C](https://stackoverflow.com/questions/101439/the-most-efficient-way-to-implement-an-integer-based-power-function-powint-int#comment737605_101439).
> **Comments:**
> **username_10** (2023-07-03): `^^` could also work, no?  
> **username_9** (2023-07-03): So `2.0^3` is 8, but `2^3` is 1?  That would *easily* cause confusion.  
> **username_2** (2023-07-03): +1 for the double star, -1 for the floating-point-only solution. Is it even implemented anywhere?  
> **username_11** (2023-07-03): Haskell uses [`^`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-94-) for non-negative integral power, [`^^`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-94--94-) for possibly-negative integral power, and [`**`](https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#v:-42--42-) for floating-point power. Btw I agree that overloading the same operator `^` for integer XOR and floating power is probably not a good idea.  
> **username_12** (2023-07-05): python3 does ** and i like python3 so, there is my very biased comment why i believe this is a good answer  
---
### Answer by username_16 on 2023-07-03. Score: 7
## Unicode

See for examples:

* <https://en.wikipedia.org/wiki/List_of_logic_symbols>
* <https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode>

# Powers

### Superscript for powers

23

Downsides:

* It seems this has to be [implemented as a style](https://stackoverflow.com/questions/76616411/is-there-a-unicode-combiner-akin-to-a-superscript-style). There is no simple unicode combiner trick.
* That gives it the same risks as giving semantic meaning colour or italics but you could if you were willing to accept  in an ASCII version of your code.
* It could also get messy if you want nested powers like 234

Based on that I have to prefer the simple obvious and (not wrong) suggestion of:

### Double star

As suggested in <https://langdev.stackexchange.com/a/1960/285>

> Many languages have a \*\* operator for exponentiation. This is reasonably intuitive, as exponentiation is just the hyperoperation after multiplication.

Though there is no reason a clever IDE couldn't render that as a superscript I suppose but it might cause some *cognitive stress*.

## Prior art

As helpfully pointed out in response to [my question](https://math.stackexchange.com/questions/4731159/symbols-for-exponentiation?noredirect=1#comment10028651_4731159) that wikipedia mentions:

* x ↑ y: Algol Reference language, Commodore BASIC, TRS-80 LevelII/III BASIC.[45][46]
* x ^^ y: Haskell (for fractional base, integer exponents), D.
* x⋆y: APL.

The up arrow has other meanings including the next [hyperoperation](https://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation) up from exponentation.

APLs use of a single star is bound to cause confusion for users thinking in ASCII. APL uses × for multiplication.

# Logic

### veebar or oplus for xor

⊻
⊕

---

## consider IDE support

You could have your IDE do things like automagically convert `**` to superscript and `v_` to ⊻ say.
It would not surprise me if there are relative common key shortcuts for these already and they are just not more widely known.

It is obligatory to remember [trigraphs](https://en.wikipedia.org/wiki/Digraphs_and_trigraphs) at this point and note that they have [only recently](https://stackoverflow.com/questions/27601706/c17-why-not-remove-digraphs-along-with-trigraphs) been purged from languages like C++.

Off topic but it would be nice to be able to standardise on something like:

* <http://terathon.com/blog/a-mathematical-keyboard-layout/>

Defining a "meta key" for maths and one key for each common symbol so you don't have to type the Unicode in full.
> **Comments:**
> **username_17** (2023-07-04): How do you actually want to represent the superscript in the source code, assuming it's still plain text? [With other Unicode](https://en.wikipedia.org/wiki/Superscripts_and_Subscripts_%28Unicode_block%29)? Or with actual HTML tag text?  
> **username_16** (2023-07-04): That is a good question - see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts . Superscripts should be a style but in unicode they seem to be hardcoded.  
> **username_16** (2023-07-04): I've asked it https://graphicdesign.stackexchange.com/questions/161520/is-there-a-unicode-combiner-akin-to-a-superscript-style  
> **username_16** (2023-07-05): Based on https://stackoverflow.com/questions/76616411/is-there-a-unicode-combiner-akin-to-a-superscript-style superscript has to be done as a style / rich text not as pure unicode  
> **username_17** (2023-07-05): There are superscript digit symbols, but that doesn't get you arbitrary expressions for exponents, nor nested exponents.  
---
### Answer by username_13 on 2023-07-04. Score: 4
** is fairly common. Speaking personally, I strongly dislike "identifiers that parse like operators" of which the most notorious is Pascal's inline mod. Unicode is best avoided at least in a base language (i.e. it would be a nice thing to be able to construct custom Unicode operators on a project- or site-specific basis).
I think the best solution would be to make it strongly depend on the type of the operands, i.e. to distinguish between bytes etc. which can be xored, anded etc. and integers which can be added and multiplied. In fact I came across this a year or so ago written as (in part) a criticism of APL's odd parsing:

...one need only deal with operators that have the same kind of operand, i.e. that have the same domains. For example, A + B > C must imply comparing A + B with C, because A + B gives a numerical sresult whereas B > C gives a logical result and one cannot add a number and a logical value, despite APL and PL/1 pretending that one can. There is, therefore, no need to establish relative precedences for + and >. P.A.Samet, UCL, circa 1975.

https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380050310
My holy grail is a moderately efficient parser which can handle the ambiguities relating to monadic/dyadic ^ (dereference, xor, exponentiation) and monadic ! (negation, factorial) as well as Smalltalk-style keywords.
Looking back through some notes, ! is an interesting case particularly if we would also like it to be a dyadic operator to suit e.g. APL's combination operator.
x!       x factorial
!y       y negated, only valid if y is a boolean
!!z      Integer z converted to a boolean
a ! b   Number of combinations of b taken in groups of a
a! b    Can't be postfix factorial, lacks a dyadic operator
a !b    Can't be prefix negation, and b not a boolean
a !!b   Invalid, lacks a dyadic operator
a! ! b  Number of combinations of b taken in groups of a! (a factorial)

What I concluded from that type of exercise is that a character could be used for a fairly wide mix of operators including type-dependent local definitions, but that the situation could be improved enormously if there were an initial (i.e. project level) declaration of what characters and character sequences should be considered valid operators with association rules etc. and that definitions were not allowed to vary this.
> **Comments:**
> **username_14** (2023-07-04): Is your proposal to have no types that support both bitwise and arithmetic operations?  So [bithacks](https://catonmat.net/low-level-bit-hacks) such as clearing the lowest set bit (`x &= x-1` in C) would need casts to different types for the `-1` and the `&`?  
> **username_13** (2023-07-05): Well, it's just a "thought experiment" at the moment but I think it's a question of favouring the most common usage for each operation. In addition, once the parser has chosen the correct operation the optimiser should be able to eliminate any overhead introduced by casting.  
> **username_15** (2023-07-05): `**` doesn't work well particularly well for C or C++, because `*` as a unary operator (dereference) can be needed multiple times (unlike unary `+` or `-`).  But it is indeed common in languages without a unary `*` operator.  
> **username_13** (2023-07-05): I can assure you that C is the last thing on my mind :-) Besides, which, successive dereferences work perfectly well if the referent is itself a pointer: the real problem in this area is languages like Object Pascal (as implemented by Delphi) which allow the unary dereference operator (^ in this case) to be omitted under certain circumstances.  
---
