On Sun, Nov 14, 2021 at 8:42 PM Paul Smith <psm...@gnu.org> wrote: > > 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.
What I was trying to say is that the two versions differ only in the abilities provided by their thee-argument forms. It's not much of a reason to favor one over the other, but the three-argument form of the original proposal (less-than) is 'complete' in the sense that all of <, >, =, and their negations can be expressed as boolean combinations of it. The same is not true of the three-argument form of the alternative design (e.g. less-than cannot be expressed using the three-argument version of that design alone). > 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. It may be obscure, but how about we implement this as well? Sure, the two-argument form of $(compare) will be a little inconsistent, but it may be useful. > > 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. Interesting. The fact that I saw the mental model of the LT, EQ, GT ordering of outcomes reflected so often was convincing for me that this would be the more unsurprising design. I'm not saying the alternative will cause cognitive dissonance, just that the occasional user of make might not need to consult the reference documentation as much trying to recall how the compare function works. Admittedly, the difference, if any, will likely be negligible. Regards, - Jouke P.S. I started this series saying that I see no merit in discussing possible extensions and alternatives. Regarding version comparison (a minefield if you ask me), I'd just like to point out that you can do basic parsing of a version with $(let major minor patch, $(subst ., ,$(version)),<comparison_logic>)