Missing python-like chaining in D (page 2)

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.

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

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.

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.

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, 2022

Re: Missing python-like chaining in D

Posted by Paul Backus
in reply to Dom DiSc

Permalink

Paul Backus

Posted in reply to Dom DiSc

Permalink

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

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.

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

Forums