Will they ever be supported? It would have been nice to have expressions like this
x ± y
±(x, y)
Will they ever be supported?
Yeah I like them and I expect the opposition to eventually die out. :-) Unicode also has nice new forms of brackets I would like to use...
no
proc `±`(x, y: int): auto = (x, y)
let a1 = `±`(2, 3) # ok
let a2 = 2 ± 3 # CT error
but it's unclear whether it's a good idea to support because:
is this supported now?
No but feel free to write an RFC please. So far very few people requested it. Maybe most programmers are stuck in 1970. :-)
typing is awkward: yes maybe, although many things are reachable by option or can be if you want but it would be nice to allow the user to decide for oneself. But, consider that it can be very comfortable for teaching purposes, i.e. showing mathy versions of nim code which describe some algorithm (this is one use case where Julia really shines and it's certainly not a useless one).
unicode symbols look alike: yes that's something to look out for, but perhaps the Julia team has done all the work already? https://docs.julialang.org/en/v1/manual/unicode-input/
compiler: yes, Julia has the following: parsed with the same precedence as +:
+ - ⊕ ⊖ ⊞ ⊟ ∪ ∨ ⊔ ± ∓ ∔ ∸ ≏ ⊎ ⊻ ⊽ ⋎ ⋓ ⧺ ⧻ ⨈ ⨢ ⨣ ⨤ ⨥ ⨦
⨧ ⨨ ⨩ ⨪ ⨫ ⨬ ⨭ ⨮ ⨹ ⨺ ⩁ ⩂ ⩅ ⩊ ⩌ ⩏ ⩐ ⩒ ⩔ ⩖ ⩗ ⩛ ⩝ ⩡ ⩢ ⩣
* / ÷ % & ⋅ ∘ × ∩ ∧ ⊗ ⊘ ⊙ ⊚ ⊛ ⊠ ⊡ ⊓ ∗ ∙ ∤ ⅋ ≀ ⊼ ⋄ ⋆ ⋇
⋉ ⋊ ⋋ ⋌ ⋏ ⋒ ⟑ ⦸ ⦼ ⦾ ⦿ ⧶ ⧷ ⨇ ⨰ ⨱ ⨲ ⨳ ⨴ ⨵ ⨶ ⨷ ⨸ ⨻
⨼ ⨽ ⩀ ⩃ ⩄ ⩋ ⩍ ⩎ ⩑ ⩓ ⩕ ⩘ ⩚ ⩜ ⩞ ⩟ ⩠ ⫛ ⊍ ▷ ⨝ ⟕ ⟖ ⟗
and that's all. (citation: https://stackoverflow.com/questions/60321301/user-defined-infix-operator)
if it isnt obvious: I would loooove to see this implemented :)
parsed with the same precedence as +:
who's gonna remember that when reading code though? in practice, that'll mean you'll end up adding parens to disambiguate, eg:
(a ⊞ (b ∤ c) ⩕ d)
the main use case for this would be code golf/obfuscation challenges, or replacing APL > life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} (https://en.wikipedia.org/wiki/APL_(programming_language))
I'm not in a hurry to have to disambiguate between those when reading code:
a * b vs a ∗ b
⊙ vs ⦿
& vs ⅋
⋅ vs ∘ vs ⋄
⨱ vs ⨲
⋏ vs ⩑
who's gonna remember that when reading code though?
Julia's set seems excessive but if we restrict it to "+ like looking symbol are treated like +" and likewise for "*" and we watch out that only a couple of non-ambiguous symbols are supported then it would work.
That said, math notation has many bad parts (ab is a*b so you can only have single letter variables, operators can have obscure precedence) and one excellent part: The 2D layout mechanism that helps to spot patterns. The good part of math notation is not its many operators that happen to have made it into the Unicode standard. And Nim would benefit from more kinds of different parenthesis moreso than from more ways to define (binary?) operators.
yeah, and unicode normalization will result in that behavior, it's just something that whoever implements this needs to remember to do.
I'm not sure why the compiler would do Unicode normalization when your editor is supposed to do it.
Why would you expect editors to do normalization.
In particular I would expect that opening a file and then saving the file immediately would not result in any changes. And that editing one part of a file wouldn't change other parts of the file (unless I issued a command to, say, change line endings)
Do any real editors actually normalize? When do they do it?
Unicode in symbols are already supported: https://play.nim-lang.org/#ix=3qqw And I don't see it being misused too much. This proposal is just related to unicode in operators.
If someone wrote a package using Chinese or Hiieroglyphs extensivly they would immediately lose a big portion of their potential user base, and this fact I think is a good safeguard against miss-use of unicode. The idea of this proposal is to make it easier to read science code.
In Sublime Text I use the plugin UnicodeMath, really useful.
https://github.com/mvoidex/UnicodeMath https://github.com/mvoidex/UnicodeMath/blob/master/table.md
While we're providing easy ways to typeset unicode in different editors: for emacs there's xah-math-input:
http://ergoemacs.org/emacs/xmsi-math-symbols-input.html
which simply allows to convert things like (from input left):
+- ±
alpha α
...
Don't do that, please. Nim has a good record of cherry-picking security features from different languages, don't spoil it. And code readability and unambiguity also counts amongs them. I was glad when I realized that Nim embraces some ideas from Ada. And from my POV following runes are almost indistinguishable "⨢ ⨣ ⨤" or "⨥ ⨦".
BTW: in my opinion second main drawback of "secure" Rust language is C++-like style, densily packed with '<>:'[]*'. Good code, readable code should be easily readable even when programmer is tired or in hurry.
Nim has a good record of cherry-picking security features from different languages, don't spoil it.
This is obviously not the intention.
And from my POV following runes are almost indistinguishable "⨢ ⨣ ⨤" or "⨥ ⨦".
This is off the table. Please check the RFC ("Load more posts" button):
We are talking only about a few dozen symbols which must all be easily distinguishable.
BTW: in my opinion second main drawback of "secure" Rust language is C++-like style, densily packed with '<>:'[]*'. Good code, readable code should be easily readable even when programmer is tired or in hurry.
In the RFC there is also some example code regarding exactly this readability / ability to quickly ingest meaning.