unicode operators

[rtzui]

I think that infix functions would be nice. in haskell you can call +(1,3) (as in julia or lisp). You can write it infix 1 + 3, but you can also force infix f(a,b) ==a 'f' b. (actually not ', but rather +0060)
I would be really cool if certain range of unicode could be used infix aswell, so one could define ∈, use it like ∈([1,2,3],[2,3,9,10]) lisp style, or more intuitive [1,2,3] ∈ [2,3,9,10].

define ≟(a,b)
    a==b
end

>1≟2
false

>2≟2
true

define ∈(a,b)
 #code
end

>1∈[1,3,4]
true

And maybe a infix "keyword" would be cool as well:

function foobar(x,y)
 #code
end

5 ⍚foobar "qwertz" would be the same as foobar(5,"qwertz")
functions with names that contain nothing but +-*/%!§$?<>=#~ and a certain unicode range would be infix by default and would not need that symbol.

A nice thing that could be done would be

function >>=(a,b)
  if b
    a(b)
  end
end

[StefanKarpinski]

This could certainly happen at some point. The ∈ is a particularly good candidate. For now though, it's a pretty low priority and can always be added later. Another thing that would be nice is adding unicode aliases for multi-character operators:

• ≤ for <=
• ≥ for >=

and so on.

[JeffBezanson]

We won't do the haskell arbitrary infix thing a 'f' b, since we're out of ascii characters, but I think we can do the rest of it.

[marcusps]

In some domains this can be extremely helpful. I do a lot of quantum mechanical calculations, and so end up doing a lot of calculations with tensor product of matrices. Having ⊗ [Unicode 'CIRCLED TIMES' (U+2297)] would be preferable to 'kron', and having ⊕ [Unicode 'CIRCLED PLUS' (U+2295)] could also be very convenient.

Scala allows any function to be used in infix form, I think (or at least it is very flexible and more readable than Haskell), but this would require bigger changes to Julia.

One possibility if to allow only characters in the Mathematical Operators block of the Unicode standard to be used an infix operators, aside from the standard ones.

[pao]

I'd love to know where I defined ⊕, but I'm not sure how to grep for it without copying and pasting it. I wouldn't know how to type it, and even if we had editors with automatic replacements, I'd have to look up how to enter the right characters to get the replacement.

While it's very pretty and I get that it's helpful when comprehending code for some domains, I worry that it could be a beast to edit. See also: the APL keyboard. At least then you can look at the keyboard as a reference.

[StefanKarpinski]

@pao: this is exactly why I think this should remain "future possibilities" for now. One idea I've thought about is to have a tool that will translate any code to an equivalent pure-ascii version and back to using Unicode for operators. Could also have a special grep that knows how to look for operators in either form (i.e. knows that they're equivalent). That's obviously very Julia-centric, but in a sophisticated web-based development environment, it would be entirely possible.

[marcusps]

There is the danger of devolving into APL, but at the same rate I don't think that e.g. numpy's solution of writing A.dot(B) for matrix multiplication of narray is something that should be encouraged.

In the case of tensor/Kronecker products, writing kron(A,kron(B,C)) is much more awkward than A ⊗ B ⊗ C.

One possibility to avoid the APL/Unicode problem is to use LaTeX type notation for infix operators, and have the IDE change it automatically to the unicode op, e.g. A \kron B \kron C. This way it is always searchable and familiar for people who write papers with Mathematical notation.

[StefanKarpinski]

Definitely agree that A.dot(B) isn't very nice. That's why Julia supports all of Matlab's operators, and then some. In the case of kron, one could also write kron(A,B,C) which, while not as fancy looking as A ⊗ B ⊗ C, is still pretty readable.

One possibility to avoid the APL/Unicode problem is to use LaTeX type notation for infix operators, and have the IDE change it automatically to the unicode op, e.g. A \kron B \kron C. This way it is always searchable and familiar for people who write papers with Mathematical notation.

This assumes a non-existent IDE. Also, we're certainly not going down the Fortress path where you need some special WYSIWYG IDE for coding in the language to be reasonable. A tool that can translate to and from ASCII non-infix form and Unicode infix form is different because it's not an IDE, it's just a source translation tool.

[JeffBezanson]

I have an emacs input method that auto-converts various backslash sequences to unicode characters. I could check it in to contrib, or make it part of julia-mode if people want ;)

[ViralBShah]

I would prefer not introducing any of these unicode characters. I don't always have access to emacs when I edit julia! One could always make these optional, so that you don't have to use them - but others start using them in their codes, and it makes it difficult to work on code written by others.

[JeffBezanson]

JUST USE EMACS DAMMIT
:P

[o-jasper]

If you do this, please make all Expr results from infix operations the same. Compare :(a+b+c) with :(a|b|c), if you write macros have to deal with that. Note: for stuff that isn't associative, where the parentheses happen matters.. The programmers fault for not putting parenthesis in, (s)he is making ambiguous.

[salehqt]

I think the idea of Unicode operators is very neat, it might not be very easy to type, but it enhances readability of the code. Considering that 80% of development time is spent in debugging, having a readable code is very important (especially in numerical packages).

Contrary to what people mentioned in the discussion, problem of typing Unicode characters does not affect the language itself, Julia supports Unicode input so there is no problem there. One can always have ASCII aliases for all of the Unicode names, or better, make the ASCII name the primary form and have a Unicode name for convenience. (e.g. define the kron(a,b) function and then define the unicode operator as ⊗=kron)

Typing unicode characters is does not introduce inconsistency. I think that should be left to the user. I just changed my keyboard layout to use AltGr to type Unicode operators and Greek letters. It is also possible to have an IDE to convert LaTeX sequences (I did that with Geany). But none of these affect the implementation of operators.

I tried a small hack and it worked. I will post my code once I implement some of the operators.