4 ms·
I vigorously disagree.
by tempodox 3y ago
I vigorously disagree.
- lionkor 3y agoFor 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 that
- OJFord 3y agoYou can take any reasonable grammar and come up with unreasonably ugly/illegible code.
- lionkor 3y agoYeah, 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).
- tempodox 3y agoThe 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.)
- rfl890 3y agoThere‘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).
- bmacho 3y agoHow 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.
- samatman 3y agoThat 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?