# True == 1 weirdness

Jussi Piitulainen harvesting at makes.email.invalid
Fri Sep 18 09:10:29 CEST 2015

```Random832 writes:

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

Agreed.

(In hierarchical set theories like ZFC, the membership predicate is
between things of the same type, too: sets, the only things there are.
That's hardly relevant in a typed setting.)

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

To keep the rules simple. To keep the language comprehensible, and then
I can take the responsibility to keep my code comprehensible.

> 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

I prefer (1) with no hesitation. I start to worry about typos and
thinkos when the expression gets longer, and transitivity is such a
fundamental notion that I'd rather blame myself for not understanding
transitivity than the code for being too concise. (Also, == :)

Would really hate to be forced to spell it all out if there were more
complicated expressions in the chain.

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

Yes. Those, in (1), are sane.

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

I think (x != w != y) is ok to check that neither of x and y equals w.
Even (x < w > y) seems surprisingly clear to me: it's comparing the
extreme values to the middle value but not to each other. When in doubt,
I might add a comment next to the expression.

So in principle I agree. I just seem to tolerate more uses of chained
comparisons than you.

But longer chains are even rarer than 2-chains, and even 2-chains do not
happen so often, and when they do happen, they tend to be (j < k < n).
Shrug.

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

It's also easier to document and comprehend, and on the whole they are a
natural class. If something does go wrong, it's nice to find out that
the explanation is simple, and not yet another special case that I was
supposed to keep in mind.
```