[RFC] Operator priorities extensions

[chris hermansen]

Hi everyone, just another stick to throw on the fire here... (below)

On Fri, Nov 14, 2025 at 4:12 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > Hi People.
> >
> > On Thu, Nov 13, 2025 at 05:00:38PM -0800, chris hermansen wrote:
> >> Jose and list;
> >>
> >> On Thu, Nov 13, 2025 at 4:45 PM Jose E. Marchesi <jemarch@gnu.org>
> wrote:
> >>
> >> >
> >> > Hello people.
> >> >
> >> > There are two potential extensions regarding priority of operators
> that
> >> > I would like to explore.
> >> >
> >> > Dyadic operators are always given some priority, which is an integral
> >> > number between 1 and 9, for example:
> >> >
> >> >    prio // = 9
> >> >
> >> > The first potential extension is something that someone wrote to me
> >> > privately about: to allow using a real number as well as an integral
> >> > number.  This would expand the number of possible priorities from nine
> >> > to infinite:
> >> >
> >> >    prio // = 6.5
> >> >
> >>
> >> While my living depends on floating point numbers and I love them
> dearly, I
> >> think this is moving into sledgehammer - thumbtack territory.
> Personally I
> >> would prefer between 1 and 100, which to me would give plenty of range
> for
> >> fine tuning.
> >>
> >> Also generally I haven't seen a compelling demonstration of the need for
> >> changing it at all; I believe (I have no data to back this up) that the
> >> choice of 1 - 9 was probably based on thinking that if one had 100
> choices
> >> (or infinite) one might have trouble recalling that some operator is 49
> and
> >> the other 51 (or 4.9 and 5.1) and maybe just decide to use parentheses
> >> instead.
> >>
> >
> >
> > I totally support Chris here.
> > Real numbers for priority is a very bad practical idea.
> > In theory, it's amazing, but in practice, I only can imagine a lot of
> pain for
> > no benefit.
>
> Yes I am of the same opinion.
>
> >> >
> >> > That gives // ore priority than + and - (6) but less than / and * (7).
> >> >
> >> > The second potential extension is to allow to refer indirectly to the
> >> > priority of some other operator, by name.  So for example, if we
> wanted
> >> > // to have the same priority than the integer division operator %, we
> >> > would write:
> >> >
> >> >    prio // = %
> >> >
> >>
> >> I like this second idea as it is also good documentation, whereas "prio
> //
> >> = 4" forces one to either remember what else is 3,4,5 or to go and look
> it
> >> up.
> >>
> >
> >
> > I agree.
> > What about `prio // = prio %'? To be more consistent.
>
> I don't like the idea of having to repeat `prio' there.  Is it really
> confusing to not do so?
>

I'm ok with either, though I feel like both need to be considered from the
point of view of the position of the RHS:

   1. is "prio // = %" or "prio // = prio %" an identity declaration (I am
   so ashamed I don't know the answer to this)?
   2. if it is an identity declaration, what is the position of the RHS of
   an identity declaration (I'm even more ashamed I don't know the answer to
   this)?
   3. do the answers to the above two questions matter to the decision of
   whether or not to include the second prio? because the second prio kind of
   feels like an operator to me, which doesn't seem right.

Skipping over the answers to the above... would it not be wonderful if we
saw the definition of the "canonical priority" of an operator like (say)
"+" and then all other operators with the same priority using this
"relative expression" rather than an absolute number?  E.g.

prio + = 6;
prio - = +; co or prio - = prio + co

Which also begs the question "if priority of + is 6 and priority of * is 7,
why couldn't we expect to see

prio + = 6;
prio * = + + 1;

Which, while it seems very reasonable conceptually, is kind of a "HUH"
moment.  So I almost feel like we need a way of querying the priority of an
operator so we could write something like:

prio + = 6;
prio * = priorityof + + 1;

Perhaps I have discovered a new rabbit hole into which I can descend while
everyone waves to me and wishes me well...
-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20251114/b22cd237/attachment-0001.htm>