Worth noting, WGSL does this too, and is mostly a bit stricter than Zig: `a + b & c` and `a << b & c` are errors in WGSL but accepted by Zig. (Quick: off the top of your head, how do those parse)?
I'm thinking of doing this for symbolasm also.
ozgrakkurt
Here is a crazy idea, don’t use operators, just use functions.
Operators cause issues because it is not possible to cleanly express error output from an operator, it is not possible to express the bit-width of the operation, have to understand precedence.
All of these issues cause other downstream issues.
Why not add_u64()?
show comments
Someone
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?
show comments
skrebbel
I never realized that languages have so many strict precedence levels because that’s easier to implement than not having them.
This here seems like a very good idea and I hope other languages in active development take note. And als JS’ Prettier, which actively removes parentheses like these.
show comments
Luke2642
Saturating vs wrapping operators are so nice! Apparently compiles to 3 or 4 branchless ops on most architectures.
This is one of those ideas that is very weird if you’re approaching it from more or less traditional parsing techniques, but makes a lot of sense when you think about it.
I ended up doing a bunch of work on it in a slightly broader and more formal setting during my phd (https://dl.acm.org/doi/abs/10.1145/3571251) with the expectation that it probably wouldn’t be relevant for more mainstream languages any time soon, very happy to be wrong on that.
sheept
JavaScript does something similar for the exponentiation operator. This is a syntax error:
-a ** b
Someone who learned PEMDAS in school may argue it should be equivalent to -(a * b), while a programmer may be used to unary operators binding tightest, so (-a) * b.
Scaevolus
C/C++ obviously have far too many precedence levels, but you can easily have a more readable tower without forcing parentheses, like Go's 5 levels: https://go.dev/ref/spec#Operator_precedence
boxed
I like the compromise, although I still think operator precedence in itself is evil :P Lisp kinda made the right call by mistake.
show comments
IshKebab
This is very clearly the best design for operator precedence IMO and it's nice that Zig has converged on it. It would be good to get it as a linting/formatting rule in Rust too (maybe that already exists?).
Worth noting, WGSL does this too, and is mostly a bit stricter than Zig: `a + b & c` and `a << b & c` are errors in WGSL but accepted by Zig. (Quick: off the top of your head, how do those parse)?
I'm thinking of doing this for symbolasm also.
Here is a crazy idea, don’t use operators, just use functions.
Operators cause issues because it is not possible to cleanly express error output from an operator, it is not possible to express the bit-width of the operation, have to understand precedence.
All of these issues cause other downstream issues.
Why not add_u64()?
I don’t find the article clear on how it fixes things, but I guess that, now
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?
I never realized that languages have so many strict precedence levels because that’s easier to implement than not having them.
This here seems like a very good idea and I hope other languages in active development take note. And als JS’ Prettier, which actively removes parentheses like these.
Saturating vs wrapping operators are so nice! Apparently compiles to 3 or 4 branchless ops on most architectures.
Something very similar was in Fortress, see 16.2 here https://www.ccs.neu.edu/home/samth/fortress-spec.pdf
This is one of those ideas that is very weird if you’re approaching it from more or less traditional parsing techniques, but makes a lot of sense when you think about it.
I ended up doing a bunch of work on it in a slightly broader and more formal setting during my phd (https://dl.acm.org/doi/abs/10.1145/3571251) with the expectation that it probably wouldn’t be relevant for more mainstream languages any time soon, very happy to be wrong on that.
JavaScript does something similar for the exponentiation operator. This is a syntax error:
Someone who learned PEMDAS in school may argue it should be equivalent to -(a * b), while a programmer may be used to unary operators binding tightest, so (-a) * b.C/C++ obviously have far too many precedence levels, but you can easily have a more readable tower without forcing parentheses, like Go's 5 levels: https://go.dev/ref/spec#Operator_precedence
I like the compromise, although I still think operator precedence in itself is evil :P Lisp kinda made the right call by mistake.
This is very clearly the best design for operator precedence IMO and it's nice that Zig has converged on it. It would be good to get it as a linting/formatting rule in Rust too (maybe that already exists?).