On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote: > 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: > > > $(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.