February 22
On Monday, 21 February 2022 at 18:53:16 UTC, Timon Gehr wrote:
> On 2/21/22 10:48, Stanislav Blinov wrote:
>> On Monday, 21 February 2022 at 09:29:56 UTC, forkit wrote:
>>> It seems to me, that D is a language where python like chaining would be right at home.
>>>
>>> writeln(1 < 2 < 3 < 4 > 3 == 3); // true
>>>
>> 
>> I've no clue whatsoever how to interpret that mess,
>
> It's standard mathematical notation.
>
> E.g.: https://en.wikipedia.org/wiki/Fence_(mathematics)

I do know what it means in math (though wouldn't call it "standard"), however, it is exactly because...

> mess.c:4:23: warning: comparisons like ‘X<=Y<=Z’ do not have their mathematical meaning

...that I would not know how to interpret that mess (1 < 2 < 3 < 4 > 3 == 3), nor would I want to learn if any such rules were to be introduced, because if they were, they'd go pretty much against established language rules, and not be consistent with the rest of the language anyway (as the use of anything that can be called "standard math" is, at best, very scarce).

Call it a habit, although I'd say it's more of an allergy to error-prone practices.
February 22
On Tuesday, 22 February 2022 at 09:00:10 UTC, Stanislav Blinov wrote:
>
> Call it a habit, although I'd say it's more of an allergy to error-prone practices.

c'mon. all other matters aside...

..you can't deny, that there is beauty in this mess.

1 < 2 < 3 < 4 > 3 == 3

February 22
On Tuesday, 22 February 2022 at 10:28:56 UTC, forkit wrote:
> On Tuesday, 22 February 2022 at 09:00:10 UTC, Stanislav Blinov wrote:
>>
>> Call it a habit, although I'd say it's more of an allergy to error-prone practices.
>
> c'mon. all other matters aside...
>
> ..you can't deny, that there is beauty in this mess.
>
> 1 < 2 < 3 < 4 > 3 == 3

Nope.
February 22
On 2/22/22 10:00, Stanislav Blinov wrote:
> 
> I do know what it means in math (though wouldn't call it "standard")

You are more likely than not to find that convention in play in any at least half-serious mathematical publication, but feel free not to call it what it is.
February 22
On Monday, 21 February 2022 at 09:48:53 UTC, Stanislav Blinov wrote:
> On Monday, 21 February 2022 at 09:29:56 UTC, forkit wrote:
>> It seems to me, that D is a language where python like chaining would be right at home.
>>
>> writeln(1 < 2 < 3 < 4 > 3 == 3); // true
>>
>
> I've no clue whatsoever how to interpret that mess, [...]

it means: eval each operator separately (so the operands in the middle are evaluated twice), then AND all the resulting booleans together and call that the result.
But that is something completely different from what C does. And D is meant to either do the same as C or don't compile the construct at all.
And as what C does is different from what math does, it was decided to not allow this to compile  to avoid code to silently change its meaning.

I fully agree with this decision because evaluating an operand twice is a behaviour that could have very bad side effects.  E.g. think of this:

if(1 < (x++) < 2)

Evaluating the middle operand twice will increment x by 2!! Is this desired?! And even if it is, will it be incremented first after checking if it is greater than one or after checking it if it is smaller than two? The result may be different, and as of yet there is no rule for this defined! Which one should it be, and why?
February 22

On Tuesday, 22 February 2022 at 14:13:38 UTC, Dom DiSc wrote:

>

On Monday, 21 February 2022 at 09:48:53 UTC, Stanislav Blinov wrote:

>

On Monday, 21 February 2022 at 09:29:56 UTC, forkit wrote:

>

It seems to me, that D is a language where python like chaining would be right at home.

writeln(1 < 2 < 3 < 4 > 3 == 3); // true

I've no clue whatsoever how to interpret that mess, [...]

it means: eval each operator separately (so the operands in the middle are evaluated twice), then AND all the resulting booleans together and call that the result.
[...]
I fully agree with this decision because evaluating an operand twice is a behaviour that could have very bad side effects. E.g. think of this:

if(1 < (x++) < 2)

Evaluating the middle operand twice will increment x by 2!!

As far as I can tell Python does not actually evaluate the middle operand twice. Instead, it evaluates it once and stores the result in a temporary.

>>> def f():
...     print("f")
...     return 1
...
>>> def g():
...     print("g")
...     return 2
...
>>> def h():
...     print("h")
...     return 3
...
>>> f() < g() < h()
f
g
h
True
February 22
On Tuesday, 22 February 2022 at 14:13:38 UTC, Dom DiSc wrote:

> it means: eval each operator separately (so the operands in the middle are evaluated twice), then AND all the resulting booleans together and call that the result.
> But that is something completely different from what C does. And D is meant to either do the same as C or don't compile the construct at all.
> And as what C does is different from what math does, it was decided to not allow this to compile  to avoid code to silently change its meaning.
>
> I fully agree with this decision because evaluating an operand twice is a behaviour that could have very bad side effects.  E.g. think of this:
>
> if(1 < (x++) < 2)
>
> Evaluating the middle operand twice will increment x by 2!! Is this desired?! And even if it is, will it be incremented first after checking if it is greater than one or after checking it if it is smaller than two? The result may be different, and as of yet there is no rule for this defined! Which one should it be, and why?

No, the operand is not evaluated twice, from the language definition https://docs.python.org/3/reference/expressions.html#comparisons, op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.


February 22

On Tuesday, 22 February 2022 at 14:23:19 UTC, Paul Backus wrote:

>

On Tuesday, 22 February 2022 at 14:13:38 UTC, Dom DiSc wrote:

>

it means: eval each operator separately, then AND all the resulting booleans together and call that the result.

As far as I can tell Python does not actually evaluate the middle operand twice. Instead, it evaluates it once and stores the result in a temporary.

Ok, so this can be implemented in a logical way, but still is something completely different from what C does (which was complete nonsense), so the rule still applies: don't silently change the meaning of some code!

February 22

On Monday, 21 February 2022 at 09:39:58 UTC, Mike Parker wrote:

> >

a < b < c, are illegal:

((a < b) ? 1 : 0) < c // C rules (motivated by uniformity)
a < b && b < c // Python rules (motivated by math notation)

So we learned, this is NOT the actual python rule, as this would indeed evaluate b twice. It's something more complicated:

a < b < c

will be lowered to:

auto tmp = b;
a < tmp && tmp < c

and if the chain gets longer, even more complicated:

a > b > c <= d

will be lowered to

auto tmp1 = b;
auto tmp2 = c;
a > tmp1 && tmp1 > tmp2 && tmp2 <= d

and so on.

February 22
On Tuesday, 22 February 2022 at 13:08:17 UTC, Timon Gehr wrote:
> On 2/22/22 10:00, Stanislav Blinov wrote:
>> 
>> I do know what it means in math (though wouldn't call it "standard")
>
> You are more likely than not to find that convention in play in any at least half-serious mathematical publication, but feel free not to call it what it is.

Thanks, I most certainly will. Didn't know I needed your permission, but still, thanks!

I sometimes wonder if it's something in the air or what?..