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

91–100 of 178 posts

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

#91

Post by tom_ »

TylerE wrote: post #82
tom_ wrote: post #17

Earlier 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…

I suspect that most people here won’t get the joke. Renault pulled out of the US market 40 years ago, and was never more than a tiny player.

Better than that: the Saxo was from Citroen, who apparently haven't served North America since 1974 ;) The Renault equivalent would probably be the Clio.

(Not a big hot hatch connoisseur though, I must admit - I just remember the Saxo in particular as having a reputation of hitting a bad spot on the tradeoff graph for flimsiness/power/good sense of average member of target demographic.)

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

#92

Post by zajio1am »

For languages that have strict distinction between booleans and integers (or other non-logical types) there is the natural priority of operations:

1) algebraic

2) relational

3) logical

From this, bitwise & and | are algebraic, so they should have higher priority than relationals.

One problem is !, which as a logical operator should have much lower priority.

Another problem is ==, which could be interpreted as both relational (when used on integers) or logical when used on booleans).

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

#93

Post by dataflow »

threatofrain wrote: post #43
layer8 wrote: post #38

Earlier quoted context omitted.

There is: The neutral element for + is 0 ( x + 0 = x for any x ). The neutral element for * is 1 ( x * 1 = x for any x ). Furthermore, you have arithmetic properties like x * 0 = 0 for any x (annulation) or ( x + y ) * z = ( x * z ) + ( y * z ) for any x , y , z (distributivity). Similarly: The neutral element for OR is false ( x OR false = x for any x ). The neutral element for AND is true ( x AND true = x for any x…

I've never heard of saturation arithmetic and now it all makes sense. Otherwise I thought it was more common to think of XOR as boolean addition, and OR would be represented as xy + x + y.

Fun (but not particularly useful fact) is you can also represent x OR y as 1 - (1 - x)(1 - y). This shouldn't be too weird since x OR y is equal to NOT ((NOT x) AND (NOT y)).

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

#94

Post by djur »

thomasahle wrote: post #75
sublinear wrote: post #54

Earlier quoted context omitted.

Explicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.

I think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c". Or "a+b+c+d" is more clear than "a+(b+(c+d))". Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *. So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.

Most people might agree with that, I don't know, but I know I don't think your first example is clearer. And I've had the operator precedence rules memorized for decades. Parentheses save my brain a step.

The second example is irrelevant because addition is commutative so the parentheses are meaningless. (This is why languages shouldn't override + to be a concatenation operator.)

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

#95

Post by userbinator »

pcwalton wrote: post #21
tom_ wrote: post #17

Earlier 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…

> (Main annoying thing: a lot of compilers, even popular ones such as clang and gcc, don't actually seem to know what the precedence rules actually are, and generate warnings asking you to clarify. Presumably the authors didn't realise that C has an ISO standard, that can be consulted to answer this question? Very surprising.) The compilers do know what the precedence rules are, but they know that programmers don't r…

Alternatively, they're encouraging programmers to be stupid and ignorant, causing a dumbing-down feedback loop which is ultimately damaging in the long term.

It ain't no surprise if you see the crap that passes for software these days and the nosedive in quality, but that's a rant for some other time...

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

#96

Post by torstenvl »

JonChesterfield wrote: post #3
Sohcahtoa82 wrote: post #2

I 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.

I hate Excel for this very reason.

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

#97

Post by explaininjs »

dataflow wrote: post #20
explaininjs wrote: post #16

Earlier quoted context omitted.

a+b+c is nonzero if any of a or b or c are nonzero.

Yeah I just added that. I was hesitant initially cause you have to also note they're nonnegative, and that you're treating them like real numbers rather than mod 2.

Natural numbers are the natural numbers for me! (ISO 80000-2, of course)

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

#98

Post by akira2501 »

thomasahle wrote: post #75
sublinear wrote: post #54

Earlier quoted context omitted.

Explicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.

I think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c". Or "a+b+c+d" is more clear than "a+(b+(c+d))". Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *. So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.

    ((x**b) * a) + c
Is equivalent and is the clearer way to express it.

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

#99

Post by Terr_ »

Sohcahtoa82 wrote: post #2

I 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.

Agreed, it's quite justified: If their implicit combined behavior isn't easy-to-read-obvious to the author composing the code, then it's also problematic for any poor future-person (perhaps even the original author) tasked with reading and verifying the code. Checking parens is faster than remembering and applying the knowledge.

Plus the rules may be just different enough in different languages to trip up even those who try to remember them.

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

#100

Post by neilv »

_zagj wrote: post #81
o11c wrote: post #8

Earlier quoted context omitted.

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).

> except in broken languages, of which the only notable one is shell All binary messages in Smalltalk (messages with selectors consisting of punctuation, like !@+-, including punctuation sequences like "+-&|", if you want) have the same precedence, and the keyword variants (which short-circuit, using block arguments) and: and or: also have the same precedence (one level lower than the binary/punctuation messages), bu…

> Smalltalk [...] what r5rs Scheme should have been.

I'm a fan of both languages, but R5RS Scheme was to be an algorithmic language, and Smalltalk is a particular flavor of OO language (class-instance, single dispatch).

Would you say that doing conditionals and Boolean expressions with Smalltalk's object semantics and `ifTrue:ifFalse:` and mix of `and:` and `&` etc. is cleaner than Scheme's `if`, `and`, etc. syntax?

> 3 levels of operator precedence,

Scheme doesn't see what's wrong with fewer:

    (if (or a (and b c))
        (do-something)
        (if (or (has-pending-task)
                (and (update-task-queue)
                     (has-pending-task)))
            (process-task)))
Post reply on HN