Fractional precedences? Re: Operator precedence help
ben.franksen at online.de
Thu Sep 3 18:59:04 UTC 2020
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
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.
More information about the Libraries