Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Operators without precedence #53268

Open
jariji opened this issue Feb 9, 2024 · 4 comments
Open

Operators without precedence #53268

jariji opened this issue Feb 9, 2024 · 4 comments
Labels
kind:feature Indicates new feature / enhancement requests kind:speculative Whether the change will be implemented is speculative
Milestone

Comments

@jariji
Copy link
Contributor

jariji commented Feb 9, 2024

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.

@inkydragon inkydragon added the kind:feature Indicates new feature / enhancement requests label Feb 11, 2024
@stevengj stevengj added this to the Potential 2.0 milestone Feb 13, 2024
@stevengj stevengj added the kind:speculative Whether the change will be implemented is speculative label Feb 13, 2024
@stevengj
Copy link
Member

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
Copy link
Sponsor Member

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
Copy link
Contributor Author

jariji commented Feb 13, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature Indicates new feature / enhancement requests kind:speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

5 participants