True == 1 weirdness

[Random832]

On Thu, Sep 17, 2015, at 16:24, Jussi Piitulainen wrote:
> And I'm saying 'in', being truth-valued, is more like a comparison than
> a proper binary operation that has its value in the same set as its two
> arguments.

The problem is that except for very specialized cases (strings), the two
arguments are not (semantically, at least) in the same set as each
other, either. It may be "more" like a comparison, but it's not *really*
like either one.

> Just trying to explain what I had in mind when I said that I feel that
> 'in' is more at home with comparisons (where it is now) than with, hm,
> arithmetic operations.

Why does it have to be either one? I don't even think chaining should
work for all *actual* comparison operations.

Say you have this statement:
(1) a < b = c <= d
While it may *actually* mean this:
(2) a < b and b = c and c <= d
It *semantically* means this:
(3) a < b and a < c and a < d and b = c and b <= d and c <= d

The ones that are included logically imply the ones that are not, for
any sane definition of these operators. And if your operators *aren't*
sane, it's better to be explicit about what you are doing.

It should not be applied to any combination of operations that cannot
meaningfully be read as such a statement (e.g. mixing directions of
less/greater comparisons, or including in, is not, or != at all), or to
any values expected to have (2) not imply (3).

It being *easier to implement* to have comparison operators be a single
class and have chaining apply equally to all of them may be an excuse
for the language to allow it, but it's certainly not an excuse for
*actually* using it from a standpoint of good style and readability.