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

[Jouke Witteveen]

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:
> > +@item $(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>]])
>
> Then the rule is, if the values are equal we get the <eq> part, if lhs
> is less than rhs we get <lt>, and if lhs is greater than rhs we get
> <gt>.
>
> If <gt> is not present then the invocation devolves to:
>
>   $(compare <lhs>, <rhs>, <eq>, <!eq>)
>
> that is, the fourth arg is used for not equal.
>
> If <lt> is also not present then <eq> is used if the value is equal
> else it expands to the empty string.
>

Cool, an alternative design that has something to go for it! Here is
why I like the original design better.

The only real difference is in four-argument usage. This alternative
trades the 'ordered' nature of the arguments for favoring equality
testing. To some degree, equality testing is already possible through
string-based equality testing, and even if you really want to do a
numerical equality check, the original design allows you to do

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

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. Fortran apparently had an "Arithmetic IF", that was
also ordered as in the original design of $(compare).

Regards,
- Jouke