[m-rev.] for review: reversing operator priorities

[Mark Brown]

On Mon, Nov 7, 2022 at 12:42 PM Peter Wang <novalazy at gmail.com> wrote:
>
> On Sun, 06 Nov 2022 21:33:56 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > This implements what we discussed recently.
> >
> > The diff contains several "XXX OPS" markers noting further
> > opportunities for improvement; I would like your feedback on these.
> > I would like to resolve the ones in ops.m before commit; but intend
> > to leave the others for a later commit.
> >
> > We probably should keep the old form of the ops module around,
> > possibly named old_ops.m or prolog_ops.m, for anyone who
> > wants it. I will make the necessary changes, including to NEWS,
> > once we get to a concensus on this.
> >
> > For review by anyone.
> >
> > Zoltan.
>
> > Make higher operator priorities bind tighter.
> >
> > Mercury inherited its original system of operator priorities from Prolog,
> > because during its initial development, we wanted to be able execute
> > the Mercury compiler using NU-Prolog and later SICStus Prolog.
> > That consideration has long been obsolete, and now we may fix the
> > design error that gifted Prolog with its counter-intuitive system
> > of operator priorities, in which higher *numerical* operator priorities
> > mean lower *actual* priorities. This diff does that.
>
> While it may be counter intuitive, I don't consider it a design error.
> It's not uncommon to have lower numerical values representing higher
> priorities since it does make sense to start with the highest priority,
> and counting up from zero is obvious and less arbitrary than counting
> down from some positive value. (Or you could count down from zero but
> people prefer positive values to negative values I guess.)
> Since comma is extra special, it makes sense that it was assigned a
> round value of 1000. It's likely more important in Prolog where people
> can define custom operators, not so much in Mercury.
>
> If you think it's important, I'm not objecting to the change.

I don't object either way. A further detail worth pointing out about
commas though is that we parse commas a little bit differently in
argument lists (but not for tuples where comma is an operator as
normal), which is a bit of an anomaly, but one which we could repair
by insisting that the comma operator binds less tightly than anything
else. So in this sense it makes sense to have both a weakest and
strongest binding. Indeed, if anything, having a weakest binding makes
more sense than having a strongest (though I think we do want the
module qualification operator to be the strongest).

We have a few operators that bind less tightly than comma, though, so
making this further change would not be backwards compatible. I'm not
sure how much impact that would have in practice.

Mark

>
> Peter
> _______________________________________________
> reviews mailing list
> reviews at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/reviews