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

[Paul Smith]

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.

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.

I do agree, though, that we already have a way to test equality (via
filter-out) and although it will treat "1" and "01" as different this
is probably a rare problem.

> 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.