It looks like if on wants to define a new operator, the choice of the operator symbol is limited:
mod.BTW: I already reported the missprints in the manual by filing an issue.
You can just define const add = +
I may be misunderstanding your point?
julia> ⊙(a, b) = dot(a, b)
⊙ (generic function with 1 method)
julia> const ip = ⊙
⊙ (generic function with 1 method)
julia> rand(3) ip rand(3)
ERROR: syntax: extra token "ip" after end of expression
Stacktrace:
[1] top-level scope
@ none:1
julia> rand(3) ⊙ rand(3)
4.95720e-01
julia>
In Julia, letters are not used for infix. you can do ip(a,b) but not a ip b.
Yes, my question was: why?
Because the parser has hardcoded rules what is allowed to be an infix operator, and it was decided that only a limited list of symbols qualifies for that. That’s why you can’t define your own, because you cannot modify parser behavior.
The PDF uses Deja Vu Mono, I think, which doesn’t have all these glyphs.
I always thought that infix operators need to be somewhat special symbols, because otherwise multiplications without * and infix operators become somewhat hard to distinguish?
Technically, the ability to add suffixes like +⁽²⁾ means that the choice is infinite. But there are a finite number of codepoints allowed for the first character — a mere 607.
See julia#16985 and julia#39355, where @mbauman wrote:
This would be a very large change as it would no longer make parsing canonical. Parsing itself would become stateful — and that’s something that I know Jeff is very reticent to do.
There are some gnarly parser questions here, but I think also that a lot of the interest in this simply dried up once we got all those Unicode infix symbols, and especially after operator suffixes were supported. This covered most of the things that people would like to use custom infix operators for.
Infinite, that would be good enough for me. 