Hacker News Reader

Comment by Someone | Hacker News Reader

I don’t find the article clear on how it fixes things, but I guess that, now

  a op1 b op2 c

is an error if op1 is unequal to op2 and they have the same precedence. Do I see that right?

Also, it seems each operator will have to have a associativity to handle a future operator for exponentiation or (also potential future) custom operators.

Finally, the “What you need to know” section doesn’t mention orelse. Where does that fit in?

View on HN

The point is that there is no longer a global ‘precedence number’ where the operator with the higher precedence binds tighter. Instead, it is only valid to write your example for some combinations of op1 and op2; other combinations will require explicit parentheses.

Presumably orelse is not in the table because it requires parentheses for any other operator.

I would hope they implemented it with precedence numbers, as any other way is likely to be harder to write and lead to inconsistencies.

It’s harder to write because users will want to use expressions with more than one operator such as

   b * b - 4 * a * c
   a * b + c * d > e * f and g < h

The first expression is fine, as it uses extremely commonly known precedence rules. The second is more arguable.

However, the following expressions should be invalid in any language, and no one should write them even in languages where they are unfortunately allowed:

  a + b >> c & d && 0 % 9

  a >> 4 ? b : c & d ^ 7

Given strict left to right parsing I don't see the issue with either of those examples (setting aside that perhaps bool % int ought to trigger a type error). The second example in particular seems perfectly sensible when read this way.

Note that I view ? as a language construct rather than an operator. If for whatever reason someone insisted on including that in the strict left to right requirement the second example still works and is easy to read. I just don't like those semantics as much because the parenthesis in something like a ? ( b >> c ) : d are otherwise unnecessary. The implicit parenthesis of expr ? expr : expr seems preferable to me.

Contradicting highly ingrained precedence rules for the common operations (+, -, ×) is a huge flaw for strict left to right parsing.

And for ?:, only the part between the ? and the : is implicitly paranthesized. In "a && b ? c : d || e", you need operator precedence to decide if this is "a && (b ? c : d) || e" or "(a && b)? c : (d || e)" or any other combination. So you have to define the precedence of ? and : in relation to other operators in order to define the syntax of your language, so I think it's normal to consider it an operator as well (and I'd say the same for Python's if/else conditional expression, "a if b else c", this is not about the characters used).

> is an error if op1 is unequal to op2 and they have the same precedence. Do I see that right?

It doesn't look like it works that way; only some operator classes are "unchainable".

An older PR description gives more information: https://github.com/ziglang/zig/pull/25275 (There's also a small mention of keyword operators, which I presume `orelse` is. There's a nice diagram showing the precedence classes here: https://codeberg.org/ziglang/zig/pulls/30160#issuecomment-20...)

Reply on news.ycombinator.com