julia icon indicating copy to clipboard operation
julia copied to clipboard

Operators without precedence

Open jariji opened this issue 1 year ago • 3 comments

People often want to define unicode operators but it's not obvious or universal what their precedence should be. One idea I like is to define some operators without precedence, so that any ambiguity can be resolved by parentheses. It's obvious to the reader what is happening, and there is no need for different users to argue about what the precedence should be. Moreover, in the common case where only one operator call is used, there is no need for parentheses at all.

jariji avatar Feb 09 '24 20:02 jariji

Seems like this would have to be a 2.0 thing, if it's practical at all. We certainly can't change any of the existing infix operators to behave this way.

The basic issue here is that operator precedence is determined by the parser, which acts before any user definitions are loaded.

Closely related to #16985.

stevengj avatar Feb 13 '24 19:02 stevengj

Also related: #18714 I think without more specifics this issue isn't actionable though. If there is a new proposed operator we don't yet parse, it can be added in this way, or if there are existing operators that should be changed (ergo 2.0) they should be listed explicitly.

JeffBezanson avatar Feb 13 '24 20:02 JeffBezanson

One that might even be doable in 1.x is 2 .^ 1:5 which I can't imagine anybody doing on purpose.

As for 2.0, I think perhaps even most operators might be better off with this treatment absent some strong particularized argument for each one (such as the strong and universal convention on +-*/^() etc). Supporting code like w ⩋ x ⩍ y ⩎ z does no favors for readability, at least for me.

jariji avatar Feb 13 '24 20:02 jariji

this question might be dumb, but what is preventing treating consecutive operators as a new operator?

putianyi889 avatar Feb 21 '24 10:02 putianyi889