Am 03.09.20 um 00:29 schrieb John Cotton Ericson:
I definitely prefer this approach. I do not like absolutely levels, whether natural numbers or fractional. At the end of the day, that's all order-maintance for a *global* total preorder, and such a design will always result in unforeseeable interactions between independently-developed operators, not to mention increasingly ludicrously-precise fractions.
This may sound like low-priority design pedantry, but I suspect (probably because I myself was taught with scheme) that spooky-action-at-a-distance precedence greatly harms beginning programmers, causing confusion or at least delaying the understanding that expressions are arbitrarily deep trees.
Isn't declaring relative precedences between operators also somewhat spooky-action-at-a-distance for (human) readers of the code? I think the idea is nice in principle, but I guess to make it practical requires IDE support in order to figure out the relative precedences of operators in an expression. As soon as you can define new operators, precendence is a huge problem. And the problem here is *not* designing the most flexible way to assign precedences, but rather the opposite: to *limit* flexibility so that humans can still correctly parse code at a glance. That is, IMO, the main reason why having a small and fixed number of precedences is a good thing. And yes, I have often been in a situation where I would have liked to say "make this operator bind stronger than X, but weaker than Y", but couldn't because there was no level in between X and Y. So now I have to write a few more parentheses then I would like. I still think that code is more readable with a fixed number of precendence levels, so I am willing to pay that price. Cheers Ben