Hacker News Reader

Comment by Joker_vD | Hacker News Reader

> When read procedurally (left to right) it is quite okay though,

Except that there are almost no circumstances in which "((a & b) + c) >> d" is a sensible expression. The only reasonable interpretation is "(a & b) + (c >> d)", and even then that plus is suspicious.

In practice, the worst offenders are "a & b >> c" and "a & b << c". The first expression is usually intended to mean "(a & b) >> c" — it's a bitfield extraction; the second one is usually intended to mean "a & (b << c)" — it's clearing of all but one bitfield. As you can see, those semantics are impossible to achieve with << and >> having the same precedence.

View on HN

> > When read procedurally (left to right) it is quite okay though,

> Except that there are almost no circumstances in which "((a & b) + c) >> d" is a sensible expression.

That doesn't seem like a convincing argument to me. The question is whether or not the rules set you up for scenarios where misunderstandings are likely. Strict left to right does not - for example, given a & b << c it is immediately clear that the desired interpretation is not the actual one while b << c & a will unmistakeably do what you want.

> The question is whether or not the rules set you up for scenarios where misunderstandings are likely.

No, this is a misleading statement of the problem because it tacitly assumes that programmers write arbitrary expressions with almost the same probability, so the rules should accommodate them all, at the same expense. This is patently false, and is a horrible policy for any UI/UX/DevEx/etc. designer. The very existence of linters and static analyzers, hell, even the warnings in the modern compilers about suspicious operator precedence and "this expression doesn't mean what you probably think it does" — all that suggests that some kinds expressions are more probable than others; ergo, those should be accommodated for at the expense of the unlikelier ones. So, the precedence levels and PEMDAS it is, instead of the abstractly-pure, from-the-first-principles, strictly left-to-right order which makes only its inventor, with a very peculiar kind of mind, happy at the expense of most of the actual programmers and users of the language.

honestly speaking, I think that shifts would almost always be better represented with functions, like lsl(a, 4), which solves the shenanigan between arithmetic/logic shift too.

In that case, I'd rather just have explicit bitfield getter/setter functions à la

    slct(var, 6, 2) = expr;  // var = (var &~ (0b111111 << 2)) | ((expr & 0b111111) << 2);
    var = slct(expr, 6, 2);   // var = (expr >> 2) & 0b111111;

Freaking BCPL had those in 1976, and that language was more primitive than C (it didn't even have any types beyond "machine word, reinterpreted accordingly to the operation applied to it").

Reply on news.ycombinator.com