RFC: Add some unicode function synonyms and infix operators

[jiahao]

Closes #552.

[simonbyrne]

Some other useful ones:

• ∈ for in
• ⊆ for issubset (hey that one is already used in the help)
• ∩ for intersect
• ∪ for union
• · for dot

[simonbyrne]

@jiahao if you do use √, please let us know, as it will break Distributions.jl

[jiahao]

Oh, does Distributions use √ already?

[simonbyrne]

In some of the constants, but they could easily be renamed.

[jiahao]

I think the constants are fine. You'd have to write √(2) or 4 √ 16 with the proposed additions.

[StefanKarpinski]

The √ operator should be made to behave like the minus sign (but with different precedence probably) – unary prefix and binary infix – at which point it will break that code.

[my-little-repository]

Beware of the mismatch between △, which is used to denote symmetric difference of sets, and setdiff. Setminus would be a more appropriate name for the function setdiff. Also one could add a symdiff function to base and associate it to △.

math> {1,2,3}△{3,4,5} = {1,2,4,5}
julia> setdiff({1,2,3},{3,4,5})'
1x2 Array{Any,2}:
1 2
The unicode set minus character is ∖ aka \u2216 and can be confused with the backslash .
Side by side: ∖\

[simonbyrne]

Yeah, I would agree on △: it's used for too many other things to make it standard (also, it would probably cause issues if we try to normalise, as its also the greek capital delta)

[jiahao]

The commit message is wrong; I had set △ as symdiff. The nice thing about multiple dispatch is that this makes △ available as an infix operator for other purposes in other contexts.

Also (thank goodness), not even NFKC wants to normalize the upright white triangle to the Greek Delta.

julia> normalize_string("△", :NFKC) == normalize_string("Δ", :NFKC)
false

[simonbyrne]

Ah, I see. I guess the other problem is that it's not a unicode math operator: it's actually under geometric shapes

[my-little-repository]

Ah, symdiff exists, I didn't know it has been implemented. Nice. Note that there are other unicode characters that look like a triangle.
△ \u25b3 WHITE UP-POINTING TRIANGLE
Δ \u394 GREEK CAPITAL LETTER DELTA
∆ \u2206 INCREMENT
BTW, I am fine with △ as symdiff.

[jiahao]

@simonbyrne Yes, I cheated. :)

[jiahao]

Done with laundry so I'm going to stop here for now. Happy 🚲🏠ing ⌂

[stevengj]

My feeling is that any Unicode codepoint from category Sm whose documented meaning and/or only common interpretation is as an infix operator (e.g. ⊕) should be parsed as such, to allow the user to assign methods to them.

The only question would be precedence, but nearly all such operators have clear analogies to existing operators (e.g. ⊕ and +, ⋐ and <, or ⋀ and &&) and hence it is reasonable to parse them with the same precedence.

[jiahao]

Eventually supporting all Unicode-representable infix operators could be something worth doing, but it's a bit too much to type in manually. Also, as @JeffBezanson points out, having hundreds of operators means that the parser will have to be rewritten to be cleverer at identifying them beyond the current linear search method.

[stevengj]

If you look at category Sm, most of the symbols are not unambiguously infix; there's probably a couple hundred unambiguous infix operators at most, and this is practical to type manually. It's pretty essential to go through them manually, actually, in order to intelligently categorize them.

But I agree that we would need to switch to (e.g.) a hash table instead of linear search.

[jiahao]

there's probably a couple hundred unambiguous infix operators at most, and this is practical to type manually

So, about that UROP student...

[stevengj]

shouldn't ∩ have the precedence of & and ∪ have the precedence of |?

[stevengj]

@jiahao, I made a quick pass through category Sm, and here are the symbols that seemed (a) unambiguously infix and (b) had a clear analogy to existing operators so that the precedence is clear:

* like operators: ∗∘∙ ∣∤ ⁄∩∧⅋≀⊓⊗⊘⊙⊚⊛⊠⊡⊼⋀⋂⋄⋅⋆⋇⋉⋊⋋⋌⋏⋒⟑⦸⦼⦾⦿⧵⧶⧷⧸⧹⨀⨂⨅⨇⨉⨯⨰⨱⨲⨳⨴⨵⨶⨷⨸⨻⨼⨽⩀⩃⩄⩋⩍⩎⩑⩓⩕⩘⩚⩜⩞⩟⩠⫛

+ like operators: ±∓∔∨∪−∸≂≏⊎⊔⊕⊖⊞⊟⊻⊽⋁⋃⋎⋓⧺⧻⨁⨃⊍⨄⨆⨈⨢⨣⨤⨥⨦⨧⨨⨩⨪⨫⨬⨭⨮⨹⨺⩁⩂⩅⩊⩌⩏⩐⩒⩔⩖⩗⩛⩝⩡⩢⩣﹢＋

= like (comparison) operators: ∝∈∉∊∋∌∍∥∦∷∺∻∼∽∾≁≃≄≅≆≇≈≉≊≋≌≍≎≐≑≒≓≔≕≖≗≘≙≚≛≜≝≞≟≠≡≢≣≤≥≦≧≨≩≪≫≬≭≮≯≰≱≲≳≴≵≶≷≸≹≺≻≼≽≾≿⊀⊁⊂⊃⊄⊅⊆⊇⊈⊉⊊⊋⊏⊐⊑⊒⊜⊩⊬⊮⊰⊱⊲⊳⊴⊵⊶⊷⋍⋐⋑⋕⋖⋗⋘⋙⋚⋛⋜⋝⋞⋟⋠⋡⋢⋣⋤⋥⋦⋧⋨⋩⋪⋫⋬⋭⋲⋳⋴⋵⋶⋷⋸⋹⋺⋻⋼⋽⋾⋿⟈⟉⟒⦷⧀⧁⧡⧣⧤⧥⩦⩧⩪⩫⩬⩭⩮⩯⩰⩱⩲⩳⩴⩵⩶⩷⩸⩹⩺⩻⩼⩽⩾⩿⪀⪁⪂⪃⪄⪅⪆⪇⪈⪉⪊⪋⪌⪍⪎⪏⪐⪑⪒⪓⪔⪕⪖⪗⪘⪙⪚⪛⪜⪝⪞⪟⪠⪡⪢⪣⪤⪥⪦⪧⪨⪩⪪⪫⪬⪭⪮⪯⪰⪱⪲⪳⪴⪵⪶⪷⪸⪹⪺⪻⪼⪽⪾⪿⫀⫁⫂⫃⫄⫅⫆⫇⫈⫉⫊⫋⫌⫍⫎⫏⫐⫑⫒⫓⫔⫕⫖⫗⫘⫙⫷⫸⫹⫺﹤﹥＜＞

We also might consider treating some of the arrows as infix operators, since that is how they seem to be used in practice, although the precedence is less clear:

left/right arrows (precedence of = or ==?): ←→↔↚↛↠↣↦↮⇎⇏⇒⇔⇴⇶⇷⇸⇹⇺⇻⇼⇽⇾⇿⟵⟶⟷⟷⟹⟺⟻⟼⟽⟾⟿⤀⤁⤂⤃⤄⤅⤆⤇⤌⤍⤎⤏⤐⤑⤔⤕⤖⤗⤘⤝⤞⤟⤠⥄⥅⥆⥇⥈⥊⥋⥎⥐⥒⥓⥖⥗⥚⥛⥞⥟⥢⥤⥦⥧⥨⥩⥪⥫⥬⥭⥰⧴⬱⬰⬲⬳⬴⬵⬶⬷⬸⬹⬺⬻⬼⬽⬾⬿⭀⭁⭂⭃⭄⭇⭈⭉⭊⭋⭌￩￫

combination of comparisons and left-right arrows: ⥱⥲⥳⥴⥵⥶⥷⥸⥹⥺⥻

up/down arrows (precedence of ^?): ↑↓⇵⟰⟱⤈⤉⤊⤋⤒⤓⥉⥌⥍⥏⥑⥔⥕⥘⥙⥜⥝⥠⥡⥣⥥⥮⥯￪￬

…probably also ⇈⇊, although these are in category So rather than category Sm, and we might want to support other arrows in category So as infix operators too.

I probably missed some, but we can always add more later.

[simonbyrne]

@StefanKarpinski It would be nice to have some sort of inbuilt infix operator for min and max. Up/down arrows would seem like a good option, for example ↓ = min, ↑ = max, and then ⇵ = minmax.

[stevengj]

@simonbyrne, I'm skeptical of using arrows for this. If we need infix minimum and maximum, I would just make min and max infix operators.

[jiahao]

having the up/down arrows be in the equivalence class of [^] makes sense vide Knuth's arrow notation a↑b for exponentation and a⇈b for tetration.

Also ∩ ∈ [&] and ∪ ∈ [|] make sense.

[stevengj]

@JeffBezanson, does femtolisp have a hash-table implementation (or some other easy way to circumvent the performance problems of supporting lots of Unicode infix operators)?

[mlubin]

+1

[JeffBezanson]

Yes, there is a hash table.

[JeffBezanson]

Merging this for now, as I believe it covers all the uncontroversial cases.

[JeffBezanson]

I'm removing ∣ and ∤ because (1) these are too easy to confuse with the | operator, and (2) we don't want to add functions to base that only have unicode names.

[JeffBezanson]

Also △ is in the geometric shapes category, so it's not clear that it should be an operator.