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

[Mark Brown]

On Mon, Nov 7, 2022 at 1:51 PM Mark Brown <mark at mercurylang.org> wrote:
>
> 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.

Hmm, the obvious one is semicolon.

> I'm not
> sure how much impact that would have in practice.

A lot then. :-(

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