Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dennis Ritchie on the priorities of && || vs. == etc. (1982)

lysator.liu.se

Post reply on HN
Print view View original

151–160 of 178 posts

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#151

Post by rcxdude »

leereeves wrote: post #149
goto11 wrote: post #137

Earlier quoted context omitted.

Thank you for this additional context. So in short, bitwise operators have lower precedence than comparisons to allow you to write: if (a==b & c==d) ... but of course, this means you can't write bitwise checks like this: if (addr & mask == 0) ... The problem could theoretically have been solved when the shortcut operators were introduced, by increasing the precedence of & and | to be higher than comparisons, but have…

Why was it important to allow you to write: if (a==b & c==d) I always thought using the bitwise operator as if it were a logical operator was simply a mistake, even though it works because false is 0 and true is 1. Edit: Mea culpa for reading and responding to the comments before the article.

I think at that point in C's development && and || did not exist: the bitwise were the only options.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#152

Post by Jenk »

tialaramex wrote: post #136

One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order. Lots of prior languages have tried either: 1. No operator precedence, expressions must use parentheses so that it's very clear 2. No operator precedence, everything just happens left to right regardless But Carbon says what if we do have preceden…

SmallTalk has the left-to-right for everything principle because everything is message passing and "operators" are just binary (as in two argument) messages which catches many out.

    2 - 1 * 5
will return 5, while many would expect -3. You must apply parentheses if you want a precedence other than ltr.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#153

Post by MaxBarraclough »

goto11 wrote: post #146
MaxBarraclough wrote: post #142

Earlier quoted context omitted.

> you could write [...] but of course, this means you can't write I found this rather difficult to read. You could write those expressions. They're legal C code. Whether they will have the expected semantics will depend on, well, what you expected. The more general problem is code that relies too heavily on precedence rules in the first place. Precedence-related bugs and readability issues are easily avoided, just us…

Sure, you can use parentheses everywhere, but the code would be quite noisy. Do you think this: ((window.location).href) == foo; is more readable than: window.location.href == foo;

I said code that relies too heavily on precedence rules. Your example doesn't do so.

In another comment [0] I mentioned that the Ada and Pony languages force the programmer to use parentheses when the expression would otherwise be confusingly reliant on precedence rules. Neither language requires unwieldy overuse of parentheses.

This C programming style advice article similarly recommends a middle-ground approach. [1]

I agree that unnecessary syntactic noise is bad (although this is essentially true by definition, as it's always a derogative). It can harm readability and make bugs more likely.

[0] https://news.ycombinator.com/item?id=38886613

[1] https://wiki.sei.cmu.edu/confluence/display/c/EXP00-C.+Use+p...

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#154

Post by djmcnab »

tialaramex wrote: post #136

One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order. Lots of prior languages have tried either: 1. No operator precedence, expressions must use parentheses so that it's very clear 2. No operator precedence, everything just happens left to right regardless But Carbon says what if we do have preceden…

WGSL (the shading language for WebGPU) has something similar[1].

For example, `a + b [1]: https://www.w3.org/TR/WGSL/#operator-precedence-associativit...

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#155

Post by kevin_thibedeau »

nicklecompte wrote: post #144
ahoka wrote: post #128

Earlier quoted context omitted.

Then what is _Bool, if not a built in boolean type?

I genuinely forgot stdbool.h existed, I don't actually write that much C myself. My point was more around the conditionals being weakly typed around unsigned ints rather than a specific lack of built-ins. A lot of commenters were going into arithmetic mod 2 or philosophical issues, neither of which actually apply here.

_Bool isn't part of stdbool. It's a language keyword. C23 introduces full support for bool with true and false as keywords.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#156

Post by nyssos »

ninthcat wrote: post #122
dietrichepp wrote: post #113

Earlier quoted context omitted.

Choosing false = 0 and true = 1 is putting the cart before the horse. It is equally true that 1*0=0 is the same as false|true=true, and 0+1=1 is the same as true&false=false. But it is also not true that 1+1=1, so it is probably wrong to equate 'or' with '+'. The operation has the wrong properties. As someone who sometimes dabbles in electronics, 0 = true makes a lot of intuitive sense to me. You have your pin with a…

You can interpret 0 and 1 as probabilities. 1 + 1 = 1 in this case makes sense because P(A or B) = P(A) + P(B) - P(A and B). You can interpret "A or B" as a set union and "A and B" as a set intersection. Of course it's easy to draw a three-way correspondence between Boolean arithmetic, the events represented by the empty set and the whole space, and sets within some universe because all the objects are so simple, but…

You've just moved the point where we make the arbitrary choice to here:

> You can interpret "A or B" as a set union and "A and B" as a set intersection.

{True, False, Or, And} and {False, True, And, Or} are two different naming conventions for the exact same structure: the unique boolean algebra on two elements.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#157

Post by borrow »

tialaramex wrote: post #136

One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order. Lots of prior languages have tried either: 1. No operator precedence, expressions must use parentheses so that it's very clear 2. No operator precedence, everything just happens left to right regardless But Carbon says what if we do have preceden…

Novel among mainstream languages, but not unseen before: https://blog.adamant-lang.org/2019/operator-precedence/

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#158

Post by [deleted] »

teo_zero wrote: post #132
User23 wrote: post #71

Earlier quoted context omitted.

Off the top of my head I can’t think of anything that should bind more weakly than the equivalence.

Really? Do you think equivalence should be weaker than && and || so that you would write if ((a==0) && (b==0)) instead of if (a==0 && b==0)

[deleted]

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#159

Post by User23 »

teo_zero wrote: post #132
User23 wrote: post #71

Earlier quoted context omitted.

Off the top of my head I can’t think of anything that should bind more weakly than the equivalence.

Really? Do you think equivalence should be weaker than && and || so that you would write if ((a==0) && (b==0)) instead of if (a==0 && b==0)

I think equivalence and equality should different operators. 2==x should be a syntax error, because equivalence compares Boolean expressions (and possibly their extensions depending on the language). Equality should be checked with the customary sign, and assignment should be some visually asymmetric operator like :=. As you say, Equality should bind more strongly than the Boolean typed operations, including conjunction, disjunction, and equivalence.

Tangentially, I wonder if

  if (a+b == 0)
generates more efficient code in presently popular languages with that syntax.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#160

Post by wruza »

pi-e-sigma wrote: post #62
MaxBarraclough wrote: post #59

Earlier quoted context omitted.

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.

I remember reading a discussion on it in a year around <= 2000 and it was a general consensus that Ada’s printed standard is too heavy to move around, let alone implement. Military/corporate-ish affinity didn’t help either.
Post reply on HN