Fractional precedences? Re: Operator precedence help

[Tikhon Jelvis]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200903/d9ee1e8a/attachment.html>