Re: Interval Comparisons

On 07/06/2024 20:57, Keith Thompson wrote:

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:

[...]

>

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.

While you should expect people reading code - and certainly those writing it - to be fairly familiar with the programming language in question, not everyone is an expert.  So when designing a language or considering its features, you have to look at what a significant fraction of users might get wrong.  I don't know how often people might get these cases wrong, but I think it has enough potential that I'd be very wary of allowing it - at least as an addition to 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;

 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.

Yes.

(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.

I agree that this is a different matter, and for languages that don't have the level of established history and practice that C does, it could be a lot less problematic to add chained relational operators.

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

Fair enough.
I /do/ find the chained relational operators (especially mixes of operators) ugly - or at least, I have not had occasion to write Python code myself where I thought a chain would look clearer than alternatives.
But "ugly" is obviously highly subjective.  The only way to ban ugly code is to do as Bart has done - develop your own language and tools for your own personal use, and never have to consider any one else's opinions or preferences!