Re:We need to talk about parentheses
by tempodox on Monday February 12, 2024 @06:28AM
(#39343715)
I vigorously disagree.
[ Parent
| on HN ]
For that example, I agree, but how about
a | b || c >> d & e * f
? I think its reasonable to say that a language should not allow thatHow about *paste Linux source code here*? Should the language C allow it? It's long and complicated, you don't even have enough time to read it, let alone to comprehend it.
The reason why this expression shouldn't compile has nothing to do with precedences (C has some odd choices here to be sure), but because of mixing incompatible types. Arithmetic integers, bitvector integers, Booleans, and possibly even floats. Conversions to appropriate types should have to be explicit. But C's type system is weak as all hell and this shit actually compiles there. (I'm only mentioning C because your example looks like it.)
There‘s no implicit type conversion here. As long as all the vars are the same type it works (albeit unpredictable if you don‘t know operator precedence for the lang).
You can take any reasonable grammar and come up with unreasonably ugly/illegible code.
Yeah, of course, but grammar can be designed as to not allow as much implicit magic.
If you can do it, someone will do it (in prod, in your product).
That expression would not pass code review around me, and a linter should flag it for sure.
But all the precedence rules you're invoking here are useful in isolation, and I see no reason why they shouldn't parse in combination. A linter can use heuristics to flag cases which should be parenthesized, a parser would need a defensible rule for failing a parse. What would that rule be?