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

[Peter Wang]

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.

Peter