Re: Interval Comparisons

On 07/06/2024 11:55, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 07/06/2024 05:53, Keith Thompson wrote:

[...]

 

There is also the C++ compatibility question.  C++ provides flexible
operator overloading combined with a poverty of available operators,
so the relational operators <, >, <= and >= are sometimes used for
completely different purposes, similar to the >> and <<
operators. Chaining relational operators would complicate this
significantly, I think.  If C++ adopted the feature it would be a mess
to support overloading, and if they did not, "a < b < c" in C and C++
would be valid but with completely different semantics.  Neither
option is good.

 I mentioned earlier that someone did a study of open source C++ code and
found no occurrences of things like "a < b < c", except for 4 cases that
were intended to be chained but would behave incorrectly.  I presume
that this study would have covered overloaded operators.
 

You helpfully quoted from that study, and it included :
- Many instances of using successive comparison operators in DSLs that
   overloaded these operators to give meaning unrelated to comparisons.
So yes, it seems that overloading the relational operators for other purposes and then chaining them is a real thing.

To me, this possibility, along with the confusion it would cause,
totally outweighs any potential convenience of chained comparisons.  I
have never found them helpful in Python coding, and I can't imagine
them being of any interest in my C code.

 I agree.  I wouldn't mind being able to use the feature, and I think
I've actually used it in Python, but its lack isn't a big problem.
 

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.

 In Python, all comparison operators (<, >, ==, >=, <=, !=, is, is not,
in, not in) have the same precedence, and chained operations are
specified straightforwardly.  They evaluate to a bool result.  Boolean
values can be compared (False < True), which doesn't seem to cause any
problems.
 https://docs.python.org/3/reference/expressions.html#comparisons
 

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

 "a == b && b == c", and "a != b && b != c", respectively, except that b
is only evaluated once.
 

If "c" is a boolean, some might think the "natural" interpretation of "a == b == c" is "(a == b) == c" - it is the current semantics in C.  Some people may think that "a != b != c" should be interpreted as "(a != b) & (b != c) & (a != c)".
It's one thing to make a rigid definition of the meaning in a language, picking a consistent set of rules of precedence and syntax.  It is another thing to make sure it matches up with the interpretations people have from normal mathematics, natural language, and other programming languages.  When there is a mismatch, you need good reasons to accept the syntax as a good language design idea - the more likely the misunderstanding, the stronger reasons you need.
To me, the potential misunderstandings of including != in chains is far too high in comparison to the meagre benefits.  The use of == could be clear in some situations (combined with strong type checking to help catch mistakes) but not others.  I could see a chain of a mix of < and <= making sense, or of > and >=, and occasionally being useful.  I don't think there is a point in allowing more than that.
After all, if all you need is to avoid evaluating "b" more than once, you can just do:
auto const b_ = b;