Re: Interval Comparisons

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

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)".

Yes, some people might be wrong.

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;

There are two separate issues here.

One is adding chained comparisons to C.  We both agree that this is
impractical because it would silently change the meaning of valid code.
(Changing the meaning of old code isn't likely to be much of an issue,
but any new code using the feature would quietly change behavior when
compiled under older C standards or when ported to C++.)

The other (arguably off-topic) is providing chained comparisons in other
languages.  Python does this well, in my opinion.  All comparison
operators have the same precedence, and the semantics of chained
comparisons are defined straightforwardly.  There are no arbitrary
restrictions, so you can write things that some people might find ugly
or confusing (if you have a language that bans ugly code, I'd like to
see it).  The meaning of `a =< b > c` or `a != b == c` is perfectly clear
once you understand the rules, and it doesn't change if any of the
operands are of type bool.  `a != b != c` *doesn't* mean
`a != b and a != c and b != c`.  (If you want to test whether all three
are unequal to each other, you can write `a != b != c != a`, though that
evalutes `a` twice.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */