this is why lisp is beautiful
[deleted]
Dennis Ritchie on the priorities of && || vs. == etc. (1982)
61–70 of 178 posts
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#62I 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.
The Ada language requires explicit parentheses in the case of a succession of different logical operators precisely to avoid precedence-related bugs. [0] In the Pony language, any expression where more than one infix operator is used must use parentheses to remove the ambiguity. [1] The Zig language considered following Pony, but didn't. [2] [0] http://archive.adaic.com/standards/83rat/html/ratl-03-06.htm... [1] http…
Ada is such an underrated language. The lack of its adoption is a testament to the old adage that technologies don't thrive or die on their technical merits.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#63There's a niche language called Sail that has & and | act as both bitwise and boolean operators. It actually works really well and isn't confusing at all after the initial "this is different". There's no real downside because it is a modern strictly typed language unlike C. On the other hand I don't know if there's a real upside either. It's not very difficult to use && and || and it serves as extra documentation, an…
I'm not familiar with Sail, but the reason for separate logical operators is that you want short-circuiting behavior. For example, in: (a != NULL) && a->x You don't want to right-hand side to be evaluated if the left-hand side is false.
I'm also not familiar with Sail, but you could have a single token ("&&") behave as either a bitwise or logical AND, depending on the context: if both operands are an boolean, operate logically, if both operands are an integer, operate bitwise. The complexity lies in what you do with mixed expressions. One solution is to just forbid them. This makes bitwise expressions nested within logical expressions more verbose (you'd need to add a cast), but I'd wager that those aren't used often in most high-level languages.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#64Earlier quoted context omitted.
Wrong. In C and C++, == has a higher precedence than && and ||, so `A && B == C && D` parses as `A && (B == C) && D`.
Wrong? Did'nt ask how C does it and clearly you did not understand my simple comment. Wtf is going on with hn? It's turning into yet another site were kids think they seem smart by intentionally misinterpreting and bickering.
WTF? Seriously, just check any C/C++ reference, equality operator has higher precedence than any logical or bitwise one.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#65Earlier quoted context omitted.
1+1=1? My maths education was a long time ago, but I triple checked with my calculator, and I'm uncertain this is quite right. My own mnemonic: SAXO. Shift, And, Xor, Or. (Like a real Saxo, it's fun to go a bit faster like this, but you do have to trust everybody involved, because any accident is probably going to end up badly for you.) And now you know the bitwise precedence as well! And this ordering actually works…
> 1+1=1? True + True = True, because "true" means "not zero" and "false" means "zero". In most all languages that permit int->bool casting, if(2) will evaluate to "true". The warnings clang and FCC generate are a style warning because it's unclear on casual reading. Even readers who know the precedence rules will typically want to insert the parentheses manually. If the meaning were undefined, the compiler would give…
It’s true as long as you don’t chain more than a couple billion Boolean checks.
More importantly, only if you don’t rely on short circuiting logic.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#66Earlier quoted context omitted.
Wrong. In C and C++, == has a higher precedence than && and ||, so `A && B == C && D` parses as `A && (B == C) && D`.
Wrong? Did'nt ask how C does it and clearly you did not understand my simple comment. Wtf is going on with hn? It's turning into yet another site were kids think they seem smart by intentionally misinterpreting and bickering.
I interpreted GP's comment as asking what the precedence of == was (assumably in C, given that we're discussing a post by Dennis Ritchie). On second read it could also be interpreted as asking what a good precedence for == would be, in which case you're absolutely right. Sorry about that.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#67I 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.
I know the priorities of these, but I still use parentheses to make the precedence explicit. I think it's just great practice -- and it makes things easier for the next dev who might have to work with the code.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#68The 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.
& vs && doesn't feel like a problem to me. & vs == is the real problem: `(val & MASK) == CONSTANT` needs parentheses due to this mistake. `a & (b == c)` essentially almost never makes sense (== gives you a boolean, and when dealing with booleans you can use && instead), yet that it what you get by default if omitting the parentheses.
The example given in the post is that & used to be the only conjunction operator, before && was added. Therefore, it was normal to write “if (a==b & c==d)”. While this is definitely not used anymore, the historical context is useful for explaining why the precedence of & is so low.
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#69Earlier quoted context omitted.
Wrong? Did'nt ask how C does it and clearly you did not understand my simple comment. Wtf is going on with hn? It's turning into yet another site were kids think they seem smart by intentionally misinterpreting and bickering.
I interpreted GP's comment as asking what the precedence of == was (assumably in C, given that we're discussing a post by Dennis Ritchie). On second read it could also be interpreted as asking what a good precedence for == would be, in which case you're absolutely right. Sorry about that.
On second read I C your point given the context. Got triggered because I feel hn is downhill lately. Cheers!
Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)
#70I 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.
You’re in good company[1]:
Do not introduce priority rules that destroy symmetry. I remember how much more pleasant the predicate calculus became to work with after we had decided to give con- and disjunction the same binding power and thus to consider p ∧ q ∨ r an ill-formed formula.