search

JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
45.75k stars 5.49k forks source link

Operators without precedence #53268

Open jariji opened 9 months ago

jariji commented 9 months ago

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.

stevengj commented 9 months ago

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.

JeffBezanson commented 9 months ago

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.

jariji commented 9 months ago

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.

putianyi889 commented 8 months ago

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