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

Precedence of user-defined |... and &... counter-intuitive in some cases #7358

Closed
vicuna opened this issue Sep 14, 2016 · 5 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Sep 14, 2016

Original bug ID: 7358
Reporter: @nojb
Status: closed (set by @mshinwell on 2016-12-08T16:02:28Z)
Resolution: won't fix
Priority: normal
Severity: minor
Target version: later
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @gasche @hcarty

Bug description

I just found out that the precedence level of user-defined operators (||) and (&&) is the same, and that they associate to the left. On the other hand, (||) and (&&) have different precedences and associate to the right (see
http://caml.inria.fr/pub/docs/manual-ocaml/expr.html).

I understand the need to have user defined operators |... and &... associate to the left given the ubiquity of composition operators such as (|>). But I wonder what is the rationale of them having the same precedence, which is confusing in the case of (||) and (&&) (as it does not coincide with that of || and &&).

@vicuna
Copy link
Author

vicuna commented Sep 28, 2016

Comment author: @damiendoligez

IMO this is a historical error that we have to live with: we cannot change the precedences now without breaking unknown amounts of code in a way that cannot be detected by the type-checker.

@vicuna
Copy link
Author

vicuna commented Sep 28, 2016

Comment author: @gasche

It may be nice to detect the non-parenthesized use and warn for people to add parenthesis (I think C implementations have related-ish warnings), but I don't know how to implement that effectively.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

I am unconvinced a patch for this would be worth the time spent. Obtuse infix operators such as ||~ are, in my experience, generally best avoided anyway as the potential for obfuscation is high. Other opinions?

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @nojb

I agree that the cost/benefit ratio seems too high to justify the effort.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

Since the original poster agrees with my assessment, I think this can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant