# Ideas for Unicode aliases for operators / keywords
**URL:** https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780
**Category:** Internals & Design
**Created:** [December 7, 2016, 2:56pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780 "2016-12-07T14:56:49Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@pitao](https://discourse.julialang.org/u/pitao)
#### Post date: [December 7, 2016, 2:56pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/1 "2016-12-07T14:56:49Z")
Code like `if x ∈ X` gives mathematicians a warm fuzzy feeling.
My experience is that it is easier to parse symbols than text – it’s more primal.
C++ ran into the issue of having to reuse a very small set of symbols, to the point where `*` means about five different things depending on context. With Unicode we can finally be free of this.
Are there any other constructs people would like to see appear in language?
I would like to see the following:
- proper set theory notation for logical-{AND/NOT/XOR} etc. [List of logic symbols - Wikipedia](https://en.wikipedia.org/wiki/List_of_logic_symbols) – did you know `⊻` is XOR? Also using the actual keywords, e.g. `and` `not`, etc.
- `\blacksquare` i.e. ■ for `end`
- alias up a couple of braces for `begin...end` blocks. If you really don’t want to use `{...}` there must be some decent Unicode equivalents.
- `|>` just looks ugly as sin, how about `→`
π
PS I am aware that the guideline is that Unicode should always be an auxiliary/alias, and that the primary token should be ASCII. But given that we are using Unicode, we may as well jump in with both feet, right?
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 7, 2016, 3:19pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/2 "2016-12-07T15:19:57Z")
I’m not so big on using Unicode characters, when there’s not a very commonly understood meaning.
For example for XOR, there are several symbols used in different domains for the XOR operation.
Instead of a Unicode character that you have to explain to people what it means and how to enter it,
both at the REPL and their editor (IF their editor has a compatible way of doing so), I’d rather have seen
`and`, `or` and `xor` added as infix operators as well as function names.
(I don’t have any problems to Unicode character _aliases_ though)
I wonder if maybe the parser could parse the different Unicode brackets, just without giving them any meaning,
(but checking that they were nested properly, when not in a string, just like it does for `(`, `[`, `{`),
so that a macro could then use them for whatever it wanted.
As far as |\>, I think you can already make a unicode character an alias to that operator.
One issue now, is that (AFAIK), there isn’t good support for the Unicode characters in the help system.
It would be very useful to have some simple way of getting the list of input methods for any character both programmatically or at the REPL ? prompt. I.e. ?∞ would give me \infty, as well as any possible methods attached to it
---
### Author:  [@pitao](https://discourse.julialang.org/u/pitao)
#### Post date: [December 7, 2016, 6:20pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/3 "2016-12-07T18:20:00Z")
Actually I will back out of that first bullet point, I would much rather see `and` `or` `xor` etc.
I feel that `&` vs `&&` is something we shouldn’t be inflicting upon beginners, why carry that over from C++ & friends?
- `and`, `or`, etc. are pretty much as concise as `&&` etc.
- Of `&` and `&&`, which one is logical and which one bitwise? The answer is only obvious to us because we already know it! Conversely `and` seems to belong in the same category as `true` and `false` i.e. all words, so it is natural that it should represent boolean operations.
- What is the evaluation of `a && b == c`? Which has higher precedence? Again it is something that must be learned, it is not always intuitive. Conversely `a > 1 and b == 2` seems to naturally suggest splitting at the `and`. Although maybe this is no more than my subjective experience.
---
### Author:  [@m-j-w](https://discourse.julialang.org/u/m-j-w)
#### Post date: [December 7, 2016, 6:52pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/4 "2016-12-07T18:52:16Z")
I’m not exactly convinced that giving unicode characters a pre-defined meaning is the right way to go, in particular if operator precedence comes along with it. There are just too many math symbols having different meaning in different mathematical and engineering domains, plus geographically regional differences. Leaving that decision to package authors seems to me the right way to go. Even though it means having to write a few brackets.
Regarding ‘missing’ unicode characters: I’m really missing \forall, \therefore, \exists and \iff along with differential operators like \partial and \nabla as possible unary and binary infix operators, e.g. to eventually implement a domain specific or symbolic syntax like `x = sin(x) ∀ (x ∈ 1..10)`, or `x = sin(x) ∀ (x > 0)`, or even `dx = ∂f/∂x` etc.
However, I’d be fully in favor of ‘and’, ‘or’, ‘not’ and ‘xor’ as infix keyword operators, and follow your (second) analysis. On the other hand, that raises the question whether those are to represent logical or bitwise operators… or both, dispatched on types Bool or Unsigned, respectively. But that again is something a user could decide if they were permitted infix keyword operators in the first place.
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [December 7, 2016, 8:47pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/5 "2016-12-07T20:47:15Z")
> [@pitao](#):
>
> I feel that & vs && is something we shouldn’t be inflicting upon beginners, why carry that over from C++ & friends?
>
> and, or, etc. are pretty much as concise as && etc.
FWIW, this has been discussed [in this issue](https://github.com/JuliaLang/julia/issues/5238). Some people are in favour of it, but it doesn’t seem the arguments were considered as compelling enough to make that change (yet?).
---
### Author:  [@pitao](https://discourse.julialang.org/u/pitao)
#### Post date: [December 7, 2016, 9:36pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/6 "2016-12-07T21:36:36Z")
15 for to 2 against looks pretty compelling to me – given that some of those plus-votes are major contributors.
I expect/hope to see that change manifest at some point!
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [December 7, 2016, 9:38pm UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/7 "2016-12-07T21:38:13Z")
> [@pitao](#):
>
> did you know `⊻` is XOR
Already [part of 0.6](https://github.com/JuliaLang/julia/pull/18977); available via Compat.jl for 0.5.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [December 8, 2016, 5:13am UTC](https://discourse.julialang.org/t/ideas-for-unicode-aliases-for-operators-keywords/780/8 "2016-12-08T05:13:41Z")
I think the problem might have been more that although many people were in favor, not that many had either the Scheme expertise, or the time (given many other worthwhile improvements to Julia on their plates), to actually make the change.