Add more unary operators

[cstjean]

Julia has an impressive list of binary operators, but the unary operators are quite lonely: (+ - ! ¬ ~ |<:| |>:| √ ∛ ∜), and most of them have existing meanings. Having a lot of operators makes it easier to define nice-looking DSLs. I can't think of too many mathematical unary operators, except maybe DAGGER † (can we have post-fix unary operators?) so perhaps we could grab ~random unicode characters (☼💣❖) and call them unary?

[StefanKarpinski]

I'm confused by the thinking here. Why would we want to make some random set of characters into unary operators?

[JeffBezanson]

There are a couple postfix unary operators, namely A' and A.'.

To add more, there needs to be an argument that a character has been used as an operator e.g. in some subfield, or that its only reasonable use would be as an operator, etc. It can't just be random characters.

[cstjean]

The sunshine suggestion was fanciful, but there aren't a whole lot of clean unary operators in mathematical notation. Most of them are diacritics or some form of brackets, and neither of those are suitable for Julia. Could we at least get the Hermitian operators † and ⊹?

Perhaps that's a different problem, but the way MacroTools handles variables: @capture(ex, f_(args__) = body_) would also be cleaner if there was a unary operator to denote "This is a variable in a pattern matching algorithm"

[JeffBezanson]

Could we at least get the Hermitian operators † and ⊹?

Those are both currently invalid characters in julia, so yes this definitely seems possible. ⊹ has unicode category Sm, the same as most other mathematical operators, so that's an easy case to make. † is punctuation, but let's see what others think. If it gets a few other votes I think we can add this.

[andyferris]

† is frequently used in superscript position... is there some way of doing this in Unicode?

[tkelman]

I think the way is "petition the Unicode committee and hope it gets included in Unicode N+1" ?

[cstjean]

@TotalVerb For what, variables in pattern-matching? $ is for plugging in values. MacroTools does the inverse: it extracts parts of an expression tree.

I want to build a tree with variables in it, and manipulate the tree. Right now it looks like tree = Node(1, 2, Node(5, Var(:x))). I would prefer tree = Node(1, 2, Node(5, ⨹:x)). I can use a macro in this particular case, so it's not the end of world. If I wanted a concise binary operation though, I would have plenty of unused, exotic operators to choose from ⨩ ⨪ ⨫ ⨬ ⨭ ⨮ ⨹ ⨺ ⩁ ⩂ ⩅ ⩊ ⩌ ⩏ ⩐ ⩒ ⩔ ⩖ ⩗ ⩛

[jebej]

Is there any way to make the dagger operator parsable as a variable name? Right now it's just invalid.

[JeffBezanson]

Yes, definitely, but we would need to decide on its syntax --- i.e. does it parse as an identifier, or some kind of operator?

[jebej]

Personally, I would use dagger as an identifier (ie part of a variable name). The complex transpose already has a symbol for it so it makes little sense to just have † do the same operation.

The exact use case I have is to store the result of something like this:

a†a = a'*a 

[StefanKarpinski]

That seems like a nice usage well aligned with how we already allow superscript integers and such.

[stevengj]

Also, the most sensible meaning for a † postfix operator would be adjoint, and we already have a postfix adjoint operator.

[chakravala]

Hi, I didn't know about this issue but I found it after posting on discourse

I think it would be really great if people could define their own unary operators. Unary operators aren't so uncommon in mathematics.

Perhaps, a special character could be used in conjunction in order to help the parser determine that it is a unary operator. For example, `! could be factorial so that one couuld do 5`! and then one could define their own unary operator, each marked by `. Another thing could be to have both left-handed and right-handed unary operators.

For example factorial would be right-handed as in 5`! but if it was defined as a left-handed it could be written as !`5.

Not saying that ` is the right character for this, but it's just an idea that some sort of syntax like that might help in clarifying what is a unary operator and what is not, to help enable people to define their own unary operators for whatever they need.