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 – did you know ⊻ is XOR? Also using the actual keywords, e.g. andnot, 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?
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
Actually I will back out of that first bullet point, I would much rather see andorxor 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.
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.
FWIW, this has been discussed in this issue. Some people are in favour of it, but it doesn’t seem the arguments were considered as compelling enough to make that change (yet?).
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.