[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH 3/3] Introduce $(compare ...) for numerical comparison
From: |
rsbecker |
Subject: |
RE: [PATCH 3/3] Introduce $(compare ...) for numerical comparison |
Date: |
Wed, 10 Nov 2021 12:48:26 -0500 |
On November 10, 2021 12:19 PM, Jouke Witteveen wrote:
> To: psmith@gnu.org
> Cc: bug-make <bug-make@gnu.org>
> Subject: Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison
>
> 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).
I have a similar function in my own fork called $(vcompare), which is similar,
but does comparison of version-like strings. It does not have the additional
arguments, which I would think are better separated off into a control function
like $(if) instead of having then and else built into the $(compare).
Randall
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/05
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/08
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/10
- RE: [PATCH 3/3] Introduce $(compare ...) for numerical comparison,
rsbecker <=
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/14
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/15
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/27
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Jouke Witteveen, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/28
- Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison, Paul Smith, 2021/11/28