On Mon, Nov 8, 2021 at 4:08 PM Paul Smith <psm...@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