In the proposals for relative precedences that I've heard before, it would be a syntactic error to use two operators that *don't* have explicitly defined relationships without parentheses. + and * would work together the way you would expect from math, but you simply wouldn't be able to mix them with ++ without parentheses. Seems like this would avoid spooky action at a distance since operators that aren't clearly related simply don't have relative precedences at all. Not sure how to handle operators like $ in a system like that though.

On Thu, Sep 3, 2020 at 12:01 PM Ben Franksen <ben.franksen@online.de> wrote:

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

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries