Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

[Jouke Witteveen]

On Sun, Nov 14, 2021 at 8:42 PM Paul Smith <psmith@gnu.org> wrote:
>
> On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote:
> > On Mon, Nov 8, 2021 at 4:08 PM Paul Smith <psmith@gnu.org> wrote:
> >
> > > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote:
> > > > $(compare 
> > > > @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}]])
> > > Let me ask this: would it be better to use a format of:
> > >    $(compare <lhs>, <rhs>, <eq>[, <lt>[, <gt>]])
> >
> >   $(if $(compare <lhs>,<rhs>,,they_are_equal,),<eq>,<!eq>)
> >
> > In fact, in the original design you could get away with just the
> > three-argument version of $(compare) in combination with $(if),
> > $(and) and $(or). This is not the case for the alternative design.
>
> Can you explain this, perhaps with an example or two?  I don't quite
> follow.  It seems that:
>
>   $(if $(compare <lhs>,<rhs>,equal),<eq>,<!eq>)
>
> works fine with the alternative syntax.

What I was trying to say is that the two versions differ only in the
abilities provided by their thee-argument forms. It's not much of a
reason to favor one over the other, but the three-argument form of the
original proposal (less-than) is 'complete' in the sense that all of
<, >, =, and their negations can be expressed as boolean combinations
of it. The same is not true of the three-argument form of the
alternative design (e.g. less-than cannot be expressed using the
three-argument version of that design alone).

> It's even possible to allow $(compare <lhs>,<rhs>) with no other
> arguments and say that if they are equal then it expands to the value,
> else it expands to the empty string, to give a very short-circuited
> equality statement.

It may be obscure, but how about we implement this as well? Sure, the
two-argument form of $(compare) will be a little inconsistent, but it
may be useful.

> > I also took a look at other languages. Nearly everywhere I could find
> > three-way comparisons, the possible outcomes are listed as LT, EQ,
> > GT, in that order.
>
> I'm certainly willing to be convinced that the original idea is better,
> but this argument doesn't hold much water for me.  I don't think that
> changing the order of the extra arguments will cause much cognitive
> dissonance for people.

Interesting. The fact that I saw the mental model of the LT, EQ, GT
ordering of outcomes reflected so often was convincing for me that
this would be the more unsurprising design. I'm not saying the
alternative will cause cognitive dissonance, just that the occasional
user of make might not need to consult the reference documentation as
much trying to recall how the compare function works. Admittedly, the
difference, if any, will likely be negligible.

Regards,
- Jouke

P.S.
I started this series saying that I see no merit in discussing
possible extensions and alternatives. Regarding version comparison (a
minefield if you ask me), I'd just like to point out that you can do
basic parsing of a version with
  $(let major minor patch, $(subst ., ,$(version)),<comparison_logic>)