Re: Interval Comparisons

On 07/06/2024 10:22, David Brown wrote:

To me, this possibility, along with the confusion it would cause, totally outweighs any potential convenience of chained comparisons.
 Even in a new language, I would not want to see chained relational operators unless you had a strict requirement that relational operators evaluate to a boolean type with no support for relational operators between booleans, and no support for comparison or other operators between booleans and other types.

And even then, what is "a == b == c" supposed to mean, or "a != b != c" ?

Some combinations are confusing, and in my languages I would suggest they are avoided (but stop short of banning them).
Ones like 'a == b == c' are straightforward: you're testing that all a, b, c have the same value.
With relational ops like 'a < b <= c', that means:
    a < b' && b' << c
with b' representing the same copy of b (which can be an arbitrary term) should be used.
However, 'a > b <= c' is not clear. While the above indicate a relationship between a and c when the whole expression is True, here you can't deduce any such relationship; all of these could be True:
   a > c, a == c, a < c
And there was one more I'd forgotten about:
    a != b != c
This looks very much like the exact opposite of ' a == b == c', but it isn't! (I think it would need a != b != c != a).
So the restrictions I would suggest are:
* Not mixing <, <= with >, >= in the same chain (any angle brackets
   should point the same way)
* Not allowing != in the chain.
Such a chain also requires that all 6 (or 5) operators have the same precedence, as you can't have 'a = b <= c' mean 'a = (b <= c)'.
 >  I
 > have never found them helpful in Python coding, and I can't imagine them
 > being of any interest in my C code.
The most common uses for me are comparing that N terms are equal (here = means equality):
   if x.tag = y.tag = ti64
   if a = b = 0
I also used them for range-checking:
   if a <= b <= c
until I introduced 'if b in a..c' for that purpose. (However I would still need 'a <= b <= c' for floating point.)
What I might then suggest for C, as a first step, is to allow only chained '==' comparisons. That avoids those ambiguous cases, and also the problem with mixed precedence, while still providing a handy new feature.