A != b != c

[pint]

@ChrisRackauckas

A linked list chain where you define a<b to mean a is immediately to the left of b? That sounds like a perfectly useful and valid dispatch for < for which it wouldn’t be transitive.

not to me. < has a very specific meaning, and it means “comes before” in some ordering. of course you are allowed to define anything, but to be useful, you need to define things in a way that makes sense to the reader. you need to build on preexisting knowledge and concepts. and we don’t need to support weird definitions either.

example. how julia knows that * has precedence over +? what if i define * and + for my type in a way that precedence should be the other way. but julia does not provide a way to define my own precedence. for + and * are reserved for use cases that match this concept. so the compiler can simply assume how they behave, because otherwise you would not use these operators.

[Tamas_Papp]

@pint

but to be useful, you need to define things in a way that makes sense to the reader

See this comment above:

A != b != c

I think you’re getting at the real problem with this kind of discussion: people don’t all have the same intuitions, so debating intuitions doesn’t generally lead to any improvements in language design.

[pint]

i think i have explained why i think this is not the case

[ChrisRackauckas]

@pint

i think i have explained why i think this is not the case

And I showed you a case where < was the obvious operator and wasn’t transitive. Our disagreement on how obvious this is proves @johnmyleswhite 's point.

[pint]

@ChrisRackauckas

I showed you a case where < was the obvious operator

and i replied that it is not only not obvious, it is objectively wrong.

[johnmyleswhite]

and i replied that it is not only not obvious, it is objectively wrong.

Please, let’s stop this thread now. Once the word “objective” gets brought into a conversation, it’s time for the conversation to stop.

[ChrisRackauckas]

It’s my bad for inciting that. I just couldn’t help myself. I think this thread should be closed: I am not sure anything useful can come out of where this has gone.

[Tamas_Papp]

@ChrisRackauckas

I am not sure anything useful can come out of where this has gone.

Perhaps some policy about discussions on surface syntax? They are started by well-meaning people, but seem to inevitably lead to discussions like this (I will not enumerate here the Github issues where this also happened). I am not saying that there could be no improvement to the Julia syntax, just that some minor barrier to entry could be useful. Eg “topic will be deleted unless there is a PR or a package implementing the suggestion, except for core developers”.

[Palli]

@Palli

is there a use case in which < is not transitive?

You omitted the above that I was answering:

@johnmyleswhite

It should be in all cases (as logic dictates), the expand you showed, only shows what the current implementations of Julia does.

You’re now actively spreading misinformation. Please stop.

[where you referring to the “expand”, as not clear you’re right then either?]

Am I missing something? I stated < is transitive in “all cases”, as logic dictates:

Transitive relation

“whenever A > B and B > C, then also A > C”

I didn’t say != is transitive. Are you assuming Julia must implement short-circuit, as “logical”?

Outdated sentence: When there are no side-effects, you do not have to evaluate in strict left-to-right [implied] short-circuit order. EDIT, turns out you do not have to (see quote from doc below).

Yes, if you can overload < [I’m stating it’s illogical, to add a meaning for < that is non-transitive] then you can’t. Julia can know if you did(?); if so, then overloading doesn’t make what I said untrue, strictly.

“However, the order of evaluations in a chained comparison is undefined. It is strongly recommended not to use expressions with side effects (such as printing) in chained comparisons. If side effects are required, the short-circuit && operator should be used explicitly”