Dennis Ritchie on the priorities of && || vs. == etc. (1982)
1–10 of 178 posts
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#2I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#3I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Consider (&& a b) and (|| a b) for no uncertainty over operator precedence and easy variadic representation (&& a b c) at the cost of zero additional parentheses.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#4Somewhere, I sat down and wrote a combined precedence table across many languages. It was quite hairy; sometimes there's even variation across language versions.
Besides `not` (which often has different precedence depending on whether it's a keyword or a punctuator, and is a great reminder that multiple levels of pratt parsing is meaningful), `await` is the one with the most variation - in most languages, it binds tighter than binary operators, whereas in C++ it's just barely tighter than assignment.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#5quite interesting. in VHDL we have a similar thing. `Edit:
on a quick glance, Ada uses the := as the assignment operator. However there seems to be only one version of the and, or, xor operators, used for both logical and bitwise.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#6I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Consider (&& a b) and (|| a b) for no uncertainty over operator precedence and easy variadic representation (&& a b c) at the cost of zero additional parentheses.
While true and might be easy to read in the example context of a b c I'd imagine having the && separator in real world conditions to be far more readable and clear for vast majority if people
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#7I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Consider (&& a b) and (|| a b) for no uncertainty over operator precedence and easy variadic representation (&& a b c) at the cost of zero additional parentheses.
Most, and possibly all languages I've used day to day do not have prefix operators like that.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#8I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Convert them to arithmetic. If you ignore the casting,
a && b is just a * b
a || b is just a + b
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#9The relative priorities of && vs ||, or & vs |, match the traditional precedence in logical expressions: "and" binds more tightly than "or", just as * binds more tightly than + ("and" is equivalent to * for one-bit values, and "or" is addition modulo 2). So I think that they got this correct.
However, the precedence of & vs &&, or & vs ||, etc is a source of problems.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#10I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).
Is there an intuition for this correspondence otherwise I don't think it's very helpful