4 ms·
This is sensible, but I don't fully understand why there is such pressure to support inherently ambiguous infix operations. I get that 1 + 2 * 3 might be margin
by thefaux 2y ago
This is sensible, but I don't fully understand why there is such pressure to support inherently ambiguous infix operations. I get that 1 + 2 * 3 might be marginally nicer to type out but 1 + (2 * 3) is completely unambiguous no matter what language I'm using. This, for me, improves readability, especially because I don't have to guess what the intention was if I'm ever confused by the result. Also, it's one thing in a math or science paper where the reader can correct the result if there is an ambiguity, but if a compiler handles ambiguity wrong, that can throw the entire program off quite significantly.
The ratio of time spent on precedence parsing in compilers to utility feels very low to me. That being said, I do appreciate the satisfaction of being able to implement it declaratively as the author does here.
- 082349872349872 2y agoLisps, Smalltalks, and APLs are among the language families that haven't bothered with precedence. (that said, I think it's worth it: an afternoon spent providing precedence is easily paid back —in an expression-oriented language, anyway— in avoiding myriad pairs of parens)
- munificent 2y agoSmalltalk does have precedence, just not among infix operators. It has keyword, infix, and postfix expressions and needs to specify the relative precedence between those. In other words, the language has to decide if: a b: c - d e Is parsed like: a b: (c - (d e)) a b: ((c - d) e) (a b: c) - (d e) (a b: (c - d)) e ((a b: c) - d) e
- anamax 2y agoI spend far more time reading code than typing it, so the time to type () is in the noise compared to the time to remember precedence rules while reading. If there were only a couple of operators, maybe precedence would be manageable, but there aren't.