forkit <forkit gmail.com> writes:

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


So why doesn't D have it already ;-)

Mike Parker <aldacron gmail.com> writes:

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


 So why doesn't D have it already ;-)

 From 'Origins of the D Programming Language' 
(https://dl.acm.org/doi/pdf/10.1145/3386323):

3.5.6 Confusing Behavior. Confusing forms allowed in C, such as 
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)

The C rules are motivated by consistency with the other parts of 
the language; all operators are associative, and most other 
binary operators are left associative. That consistency leads in 
this case to a mostly useless composition rule. Python addressed 
the matter by taking inspiration from the usual math semantics. 
Walter aimed at avoiding silently changing the semantics of code 
ported or pasted from C. The solution adopted was simple, 
robust, and obvious in hindsight: comparison operators are not 
associative in D’s grammar. Confusing uses such as a < b < c are 
syntactically illegal and produce a compiler error.

Dom DiSc <dominikus scherkl.de> writes:

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.

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 2/22/22 06:42, Dom DiSc wrote:

 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.

No, it is a little more complicated than that. Unlike your equivalent, 
Python evaluates c only if a > tmp1 is true.

Ali

Stanislav Blinov <stanislav.blinov gmail.com> writes:

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, nor do I have 
any desire of obtaining said clue.

Dukc <ajieskola gmail.com> writes:

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, nor do I 
 have any desire of obtaining said clue.

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

In a new langauge, I think it might make sense. But D is right to 
not behave that way because of the design goal to avoid silently 
changing C semantics.

forkit <forkit gmail.com> writes:

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, nor do I 
 have any desire of obtaining said clue.

It's just a chain..

just like...

cat.meow().eat().sleep().play();

which, the more verbose way, is:

cat.meow();
cat.eat();
cat.sleep();
cat.play();

Bastiaan Veelo <Bastiaan Veelo.net> writes:

On Monday, 21 February 2022 at 10:27:08 UTC, forkit wrote:
 cat.meow().eat().sleep().play();

 which, the more verbose way, is:

 cat.meow();
 cat.eat();
 cat.sleep();
 cat.play();

Not at all, not in the general case!

```d
cat.meow().eat().sleep().play();
```
is equivalent to
```d
play(sleep(eat(meow(cat))));
```
In other words, the result of `eat` is fed into `sleep`, the 
result of `sleep` is fed into `play`, etc. Your statement is only 
true if all those functions return a reference to `cat`.

-- Bastiaan.

Abdulhaq <alynch4047 gmail.com> writes:

On Monday, 21 February 2022 at 10:27:08 UTC, forkit 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, nor do I 
 have any desire of obtaining said clue.

 It's just a chain..

 just like...

 cat.meow().eat().sleep().play();

 which, the more verbose way, is:

 cat.meow();
 cat.eat();
 cat.sleep();
 cat.play();

I think you've misunderstood what this is doing in python. 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.

e.g. 2 < x < 5 means x > 2 and x < 5, i.e. x is between 2 and 5. 
It only applies to comparisons and it's a genuinely useful bit of 
syntactic sugar that is not confusing when used properly.

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 2/21/22 02:27, forkit wrote:

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



 cat.meow().eat().sleep().play();

That misunderstanding (or miscommunication) is reason enough why such 
loose semantics should not be in any serious programming language.

So, Python is happy with the fact that the result of 1 < 2 is sometimes 
Boolean but sometimes 2? (Note that in chaining, not the result but one 
of the arguments is used; and the chosen argument happens to be the one 
that's "close" to the next operator. Ha ha! :) How convenient... And why 
would 'a > b < c' not mean "a is greater than b and a is less than c" or 
"a is greater than b OR b is less than c"? I can guess: They picked the 
only semantic that could possibly be explained that could work. And then 
they must have slapped on a rationale: "Checking more than two 
conditions is very common in Programming Languages." I found that 
inaccurate sentence copy-pasted in multiple blog posts:

- They must mean "more than one condition", not "two"

- They mean "program", not "programming language"

- They ommit the supposed domain where that claim may be true (I might 
have found a use for this feature perhaps once, if ever? Not sure...)

I think this is an example of blind leading blind in that community.

Ali

Abdulhaq <alynch4047 gmail.com> writes:

On Monday, 21 February 2022 at 18:05:41 UTC, Ali Çehreli wrote:
 On 2/21/22 02:27, forkit wrote:

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



 cat.meow().eat().sleep().play();

 That misunderstanding (or miscommunication) is reason enough 
 why such loose semantics should not be in any serious 
 programming language.

 So, Python is happy with the fact that the result of 1 < 2 is 
 sometimes Boolean but sometimes 2? (Note that in chaining, not 
 the result but one of the arguments is used; and the chosen 
 argument happens to be the one that's "close" to the next 
 operator. Ha ha! :) How convenient... And why would 'a > b < c' 
 not mean "a is greater than b and a is less than c" or "a is 
 greater than b OR b is less than c"? I can guess: They picked 
 the only semantic that could possibly be explained that could 
 work. And then they must have slapped on a rationale: "Checking 
 more than two conditions is very common in Programming 
 Languages." I found that inaccurate sentence copy-pasted in 
 multiple blog posts:

 - They must mean "more than one condition", not "two"

 - They mean "program", not "programming language"

 - They ommit the supposed domain where that claim may be true 
 (I might have found a use for this feature perhaps once, if 
 ever? Not sure...)

 I think this is an example of blind leading blind in that 
 community.

 Ali

It seems you (and most of the people in this thread) have 
misunderstood what this is doing in python. 1 < 2 always returns 
a boolean, except in the case of operator overloading.

2 < x < 5 is implemented as ```(2 < x) and (x < 5)```, not as 
```(2 < x) < 5```

0xEAB <desisma heidel.beer> writes:

On Tuesday, 22 February 2022 at 08:45:53 UTC, Abdulhaq wrote:
 It seems you (and most of the people in this thread) have 
 misunderstood what this is doing in python. 1 < 2 always 
 returns a boolean, except in the case of operator overloading.

 2 < x < 5 is implemented as ```(2 < x) and (x < 5)```, not as 
 ```(2 < x) < 5```

So this is whole thing is super ambiguous.
Glad we don’t have that footgun.

- Elias

Timon Gehr <timon.gehr gmx.ch> writes:

On 25.02.22 15:02, 0xEAB wrote:
 On Tuesday, 22 February 2022 at 08:45:53 UTC, Abdulhaq wrote:
 It seems you (and most of the people in this thread) have 
 misunderstood what this is doing in python. 1 < 2 always returns a 
 boolean, except in the case of operator overloading.

 2 < x < 5 is implemented as ```(2 < x) and (x < 5)```, not as ```(2 < 
 x) < 5```

 
 So this is whole thing is super ambiguous.
 Glad we don’t have that footgun.
 
 - Elias

Not ambiguous at all. Not every expression has to be parsed as a binary 
or unary operator...

Timon Gehr <timon.gehr gmx.ch> writes:

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)

 nor do I have any desire of obtaining said clue.

A C compiler with a clue:

mess.c: In function ‘main’:
mess.c:4:23: warning: comparisons like ‘X<=Y<=Z’ do not have their 
mathematical meaning [-Wparentheses]
     4 |         printf("%d", X<=Y<=Z);
       |                      ~^~~

This is why it's disallowed in D (it's basically always an accident).

Stanislav Blinov <stanislav.blinov gmail.com> writes:

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.

forkit <forkit gmail.com> writes:

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

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

On 22.02.22 11:47, Patrick Schluter wrote:
 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.

Indeed, it's not a particularly helpful motivating example. x)

I have sometimes wished for this when checking that some more 
complicated expression is within some bounds, where the expression is 
not complicated enough to justify reshaping the code and introducing a 
temporary variable.

e.g.: low <= a[2*i+1] <= high
vs:   low <= a[2*i+1] && a[2*i+1] <= high

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Wed, Feb 23, 2022 at 02:03:37AM +0100, Timon Gehr via Digitalmars-d wrote:
 On 22.02.22 11:47, Patrick Schluter wrote:

[...]
 ..you can't deny, that there is beauty in this mess.
 
 1 < 2 < 3 < 4 > 3 == 3

 
 Nope.

 
 Indeed, it's not a particularly helpful motivating example. x)
 
 I have sometimes wished for this when checking that some more
 complicated expression is within some bounds, where the expression is
 not complicated enough to justify reshaping the code and introducing a
 temporary variable.
 
 e.g.: low <= a[2*i+1] <= high
 vs:   low <= a[2*i+1] && a[2*i+1] <= high

	import std.algorithm : ordered;
	if (ordered(low, a[2*i+1], high)) ...


T

-- 
What do you call optometrist jokes? Vitreous humor.

Walter Bright <newshound2 digitalmars.com> writes:

On 2/22/2022 5:03 PM, Timon Gehr wrote:
 vs:   low <= a[2*i+1] && a[2*i+1] <= high

If the expressions do not have side effects, any half decent compiler will not 
recompute them.

Timon Gehr <timon.gehr gmx.ch> writes:

On 23.02.22 05:31, Walter Bright wrote:
 On 2/22/2022 5:03 PM, Timon Gehr wrote:
 vs:   low <= a[2*i+1] && a[2*i+1] <= high

 
 If the expressions do not have side effects, any half decent compiler 
 will not recompute them.

Definitely, it's mostly a question of readability for me. But it's not a 
very big deal. (E.g., syntax for tuple unpacking would be significantly 
more impactful.)

Dukc <ajieskola gmail.com> writes:

On Tuesday, 22 February 2022 at 10:47:48 UTC, Patrick Schluter 
wrote:
 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.

I think the stumbling block for a C or D programmer is thinking 
the comparison operators as binary operators, so that `1 < 2 > 1` 
must mean `op!">"(op!"<"(1, 2), 1)` or `op!"<"(1, op!">"(2, 1))` 
or illegal syntax as in D. To understand the Python/Math syntax, 
you must stop this. In them, the three operands are all handled 
in one operation: `op!("<", ">")(1, 2, 1)`. There is no right or 
left associativity.

Abdulhaq <alynch4047 gmail.com> writes:

On Wednesday, 23 February 2022 at 08:56:21 UTC, Dukc wrote:

 I think the stumbling block for a C or D programmer is thinking 
 the comparison operators as binary operators, so that `1 < 2 > 
 1` must mean `op!">"(op!"<"(1, 2), 1)` or `op!"<"(1, op!">"(2, 
 1))` or illegal syntax as in D. To understand the Python/Math 
 syntax, you must stop this. In them, the three operands are all 
 handled in one operation: `op!("<", ">")(1, 2, 1)`. There is no 
 right or left associativity.

This is right. This thread got me reflecting on why python has 
been so successful in the scientific/engineering/ML domain. I 
don't think GVR was some extraordinary genius, I think he did a 
great job of coming up with a dynamic interpreted language that 
truly was 'turtles all the way down' (use of dicts throughout, 
metaclasses etc.) and managed the expansion of the language 
really well. Then numpy and scipy came along (thanks to a number 
of extremely talented engineers) and python became a very easy 
way to crunch and analyse numbers. The inherent power of python 
made it easy to build various package managers. Tkl and then PyQt 
and wxWidgets made good quality cross-platform GUI apps easy to 
build, and all along GVR prevented python going off the rails. I 
also think the 2 -> 3 transition was well timed and a success, 
contrary to what many bystanders would have you believe.

I would like to see something similar for D (i.e., making it good 
for e.g. general engineering work) but it hasn't worked out like 
that. I'm wondering why that is. Is D being wedded to C both its 
great strength, and its great weakness at the same time?

Paolo Invernizzi <paolo.invernizzi gmail.com> writes:

On Wednesday, 23 February 2022 at 09:49:33 UTC, Abdulhaq wrote:

 This is right. This thread got me reflecting on why python has 
 been so successful in the scientific/engineering/ML domain. I 
 don't think GVR was some extraordinary genius, I think he did a 
 great job of coming up with a dynamic interpreted language that 
 truly was 'turtles all the way down' (use of dicts throughout, 
 metaclasses etc.) and managed the expansion of the language 
 really well.

I program in  python since 1.8, and you are totally right. It's 
simplicity was a joy (nowadays is a little different)

 I also think the 2 -> 3 transition was well timed and a 
 success, contrary to what many bystanders would have you 
 believe.

I *strongly* agree with you. Cleaning-up the language design 
(bytes/string, print/print()) is _always_ a winning move.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Wednesday, 23 February 2022 at 10:01:21 UTC, Paolo Invernizzi 
wrote:
 I *strongly* agree with you. Cleaning-up the language design 
 (bytes/string, print/print()) is _always_ a winning move.

Indeed. Also, it is much easier to upgrade a language that is 
statically typed. In my experience the Python 2 to Python 3 
transition was a relatively smooth ride, and it can be made even 
smoother for a statically typed language.

For D specifically, you can just have a version 2 and a version 3 
front end use the same IR/backend and allow both version 2 and 
version 3 code in the the same executable.

(I have implemented "a < b < c" in an experimental extensions of 
the D compiler. It was easy to do, and isn't even a breaking 
change.)

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 09:49:33 UTC, Abdulhaq wrote:
 ... Is D being wedded to C both its great strength, and its 
 great weakness at the same time?

Perhaps, the clearest answer to that, is in the number of man 
hours (and possibly women hours, but I doubt it ;-) ..  being 
spent on ImportC.

bauss <jj_1337 live.dk> writes:

On Wednesday, 23 February 2022 at 10:12:42 UTC, forkit wrote:
 On Wednesday, 23 February 2022 at 09:49:33 UTC, Abdulhaq wrote:
 ... Is D being wedded to C both its great strength, and its 
 great weakness at the same time?

 Perhaps, the clearest answer to that, is in the number of man 
 hours (and possibly women hours, but I doubt it ;-) ..  being 
 spent on ImportC.

You can always craft up a DIP if you think the feature is so 
important and if the DIP is accepted you can always add the 
feature yourself, unless you can convince whomever is working on 
specific things in the compiler that this feature is more 
important.

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 11:08:06 UTC, bauss wrote:
 You can always craft up a DIP if you think the feature is so 
 important and if the DIP is accepted you can always add the 
 feature yourself, unless you can convince whomever is working 
 on specific things in the compiler that this feature is more 
 important.

Nowhere did I suggest this feature was 'that' important, that I'd 
consider the drawn out process of DIPing it.

Useful yes. Very useful..one can certainly make that argument.

Vital... well.. hardly. But the same can be said for many things 
'added' to languages these days.

In any case, which compiler are you referring to? The D compiler, 
or the D->C compiler ;-)

D really needs more people working on the 'D' compiler.

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Stanislav Blinov <stanislav.blinov gmail.com> writes:

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

forkit <forkit gmail.com> writes:

On Tuesday, 22 February 2022 at 15:07:12 UTC, Stanislav Blinov 
wrote:
 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?..

no. sorry. but again, you're confused.

'something in the air' is actually a hit song from 1969.

it has nothing to do with maths.

Walter Bright <newshound2 digitalmars.com> writes:

On 2/22/2022 2:05 PM, forkit wrote:
 no. sorry. but again, you're confused.

Please refrain from calling others confused. It's impolite, and besides,
there's 
always the embarassing risk that the caller is confused, not the callee.

forkit <forkit gmail.com> writes:

On Tuesday, 22 February 2022 at 22:48:59 UTC, Walter Bright wrote:
 On 2/22/2022 2:05 PM, forkit wrote:
 no. sorry. but again, you're confused.

 Please refrain from calling others confused. It's impolite, and 
 besides, there's always the embarassing risk that the caller is 
 confused, not the callee.

seriously? This was just dry humour (which should have been 
immensely apparent).

It was not an attempt to be impolite.

what's the online world coming too.. jeessssee....

Walter Bright <newshound2 digitalmars.com> writes:

On 2/22/2022 6:00 PM, forkit wrote:
 On Tuesday, 22 February 2022 at 22:48:59 UTC, Walter Bright wrote:
 On 2/22/2022 2:05 PM, forkit wrote:
 no. sorry. but again, you're confused.

 Please refrain from calling others confused. It's impolite, and besides, 
 there's always the embarassing risk that the caller is confused, not the
callee.

 
 seriously?

I've lived long enough to know that telling someone they are confused never 
results in a useful outcome.

forkit <forkit gmail.com> writes:

On Tuesday, 22 February 2022 at 22:48:59 UTC, Walter Bright wrote:
 On 2/22/2022 2:05 PM, forkit wrote:
 no. sorry. but again, you're confused.

 Please refrain from calling others confused. It's impolite, and 
 besides, there's always the embarassing risk that the caller is 
 confused, not the callee.

and in any case, the callee is confused, as the composition I 
presented, although intentionally an unintuitive one, is a 
standard form in mathmatics.

so lets now be clear, on who is confused, and who isn't.

and to suggest that confusion is == humiliation, is a ridiculous 
propostion in any case.

we are all confused, all the time. it's why we have a brain.. to 
work through the confusion.

Timon Gehr <timon.gehr gmx.ch> writes:

On 22.02.22 16:07, Stanislav Blinov wrote:
 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.

 
 ... Didn't know I needed your permission, ...
 ...

You don't. I was simply expressing bewilderment at seemingly 
deliberately ineffective communication.

Anyway, it's pretty clear that this won't be in D, though I encourage 
anyone who is interested to browse other random math-related Wikipedia 
articles and see that the notation is indeed commonly used and 
essentially never with any further explanations or references.

E.g., see here: https://en.wikipedia.org/wiki/Azuma%27s_inequality#Proof_2

I.e., it is standard. I think calling this into question is not of 
particular value.

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

I hope not. Get well soon.

Walter Bright <newshound2 digitalmars.com> writes:

On 2/22/2022 4:56 PM, Timon Gehr wrote:
 Anyway, it's pretty clear that this won't be in D,

That's right. D's behavior here been universally approved of. I originally 
thought with the size of this thread that people were going to want to change 
it, and am glad I was wrong.

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 04:27:37 UTC, Walter Bright 
wrote:
 ... D's behavior here been universally approved of. I 
 originally thought with the size of this thread that people 
 were going to want to change it, and am glad I was wrong.

That people don't want it in D, is fine. I have no problem with 
that.

But you assertion is not correct:

https://docs.julialang.org/en/v1/manual/mathematical-operations/#Chaining-comparisons

bauss <jj_1337 live.dk> writes:

On Wednesday, 23 February 2022 at 08:12:52 UTC, forkit wrote:
 On Wednesday, 23 February 2022 at 04:27:37 UTC, Walter Bright 
 wrote:
 ... D's behavior here been universally approved of. I 
 originally thought with the size of this thread that people 
 were going to want to change it, and am glad I was wrong.

 That people don't want it in D, is fine. I have no problem with 
 that.

 But you assertion is not correct:

 https://docs.julialang.org/en/v1/manual/mathematical-operations/#Chaining-comparisons

Programming isn't always 1:1 to mathematics.

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 08:34:07 UTC, bauss wrote:
 On Wednesday, 23 February 2022 at 08:12:52 UTC, forkit wrote:
 On Wednesday, 23 February 2022 at 04:27:37 UTC, Walter Bright 
 wrote:
 ... D's behavior here been universally approved of. I 
 originally thought with the size of this thread that people 
 were going to want to change it, and am glad I was wrong.

 That people don't want it in D, is fine. I have no problem 
 with that.

 But you assertion is not correct:

 https://docs.julialang.org/en/v1/manual/mathematical-operations/#Chaining-comparisons

 Programming isn't always 1:1 to mathematics.

Nobody has made that argument.

I just like the idea of being able to express:

i < n && n < x

in a mathmatically concise manner:

i < n < x

As with a lot of syntax in programming languages, of course it 
can be misused, and it also may require mental effort to master.

btw. C is no stranger to the concept of 'conciseness' ;-)

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 04:27:37 UTC, Walter Bright 
wrote:
 ... D's behavior here been universally approved of. I 
 originally thought with the size of this thread that people 
 were going to want to change it, and am glad I was wrong.

a proposal for chaining comparisons in c++

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0893r0.html

forkit <forkit gmail.com> writes:

On Tuesday, 22 February 2022 at 15:07:12 UTC, Stanislav Blinov 
wrote:
 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?..

now this is not dry humour.

it is a form of mockery - intended to humiliate the recipient of 
such.

https://www.collinsdictionary.com/dictionary/english-thesaurus/mockery/2

interesting that Walter missed this??

forkit <forkit gmail.com> writes:

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.

I accept, that 'perhaps' less distain and *confusion* would have 
emerged, had I provided a more intuitive example of the concept..


void foo(int val) if(0 < val <= (4294967295 / 2))
{
     return val * 2;
}

..nonetheless...go ahead...destroy!

Dom DiSc <dominikus scherkl.de> writes:

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?

Paul Backus <snarwin gmail.com> writes:

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

Dom DiSc <dominikus scherkl.de> writes:

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!

Abdulhaq <alynch4047 gmail.com> writes:

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.

12345swordy <alexanderheistermann gmail.com> writes:

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


 So why doesn't D have it already ;-)

Why not simply allow this?

writeln(1 < 2 and 2 < 3 and 3 < 4 and 4 > 3 and 3 is equal 3)?

-Alex

forkit <forkit gmail.com> writes:

On Wednesday, 23 February 2022 at 14:38:10 UTC, 12345swordy 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


 So why doesn't D have it already ;-)

 Why not simply allow this?

 writeln(1 < 2 and 2 < 3 and 3 < 4 and 4 > 3 and 3 is equal 3)?

 -Alex

This is not a 'must have' feature. It was just a question.

and no, your example is going in the opposite direction... i.e. 
towards unnecessary verbosity.

I want less verbosity, not more.

But D is clearly too tied to C, and becoming ever more so it 
seems.

Oddly enough, there's more chance of C++ getting chained 
comparisons ;-)

Craig Dillabaugh <craig.dillabaugh gmail.com> writes:

On Wednesday, 23 February 2022 at 19:42:53 UTC, forkit wrote:
 On Wednesday, 23 February 2022 at 14:38:10 UTC, 12345swordy

clip

 towards unnecessary verbosity.

 I want less verbosity, not more.

 But D is clearly too tied to C, and becoming ever more so it 
 seems.

 Oddly enough, there's more chance of C++ getting chained 
 comparisons ;-)

Why do people seem to hate verbosity so much!

I spend more time reading code than writing it, I suspect this is 
true for most developers, thus it would seem to make sense to 
optimize code readability vs concise and fast to write.

Of course, there are often 'win-win' cases where you can optimize 
both, but in general I think a little verbosity is better if it 
makes the code easier to read.

forkit <forkit gmail.com> writes:

On Thursday, 24 February 2022 at 17:12:19 UTC, Craig Dillabaugh 
wrote:
 Why do people seem to hate verbosity so much!

umm.. 'unnecessary verbosity' (unncessary is the keyword here, 
not verbosity)


e.g.

i < 4 < n

once you know what the above means, it will take less cognitive 
effort than

i < 4 && 4 < n

not to mention less typing.

so everyone's a winner when you remove 'unncessary' verbosity.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Feb 24, 2022 at 08:57:02PM +0000, forkit via Digitalmars-d wrote:
[...]
 e.g.
 
 i < 4 < n
 
 once you know what the above means, it will take less cognitive effort than
 
 i < 4 && 4 < n
 
 not to mention less typing.
 
 so everyone's a winner when you remove 'unncessary' verbosity.

There's std.algorithm.ordered which lets you write:

	ordered(i, 4, n)

which isn't too bad, it just needs to be promoted more so that people
are more aware of it.


T

-- 
People tell me that I'm paranoid, but they're just out to get me.

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Thursday, 24 February 2022 at 21:05:49 UTC, H. S. Teoh wrote:
 On Thu, Feb 24, 2022 at 08:57:02PM +0000, forkit via 
 Digitalmars-d wrote: [...]
 e.g.
 
 i < 4 < n
 
 once you know what the above means, it will take less 
 cognitive effort than
 
 i < 4 && 4 < n
 
 not to mention less typing.
 
 so everyone's a winner when you remove 'unncessary' verbosity.

 There's std.algorithm.ordered which lets you write:

 	ordered(i, 4, n)

 which isn't too bad, it just needs to be promoted more so that 
 people are more aware of it.

No short circuit though. Not that I suddenly changed my mind 
about the pythonese, but if we're offering alternatives, might as 
well be thorough.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Feb 24, 2022 at 09:19:38PM +0000, Stanislav Blinov via Digitalmars-d
wrote:
 On Thursday, 24 February 2022 at 21:05:49 UTC, H. S. Teoh wrote:

[...]
 There's std.algorithm.ordered which lets you write:
 
 	ordered(i, 4, n)
 
 which isn't too bad, it just needs to be promoted more so that
 people are more aware of it.

 
 No short circuit though.

[...]

The docs don't say it, but it *does* in fact short-circuit if you look
at the implementation.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Thursday, 24 February 2022 at 21:26:04 UTC, H. S. Teoh wrote:
 On Thu, Feb 24, 2022 at 09:19:38PM +0000, Stanislav Blinov via 
 Digitalmars-d wrote:
 On Thursday, 24 February 2022 at 21:05:49 UTC, H. S. Teoh 
 wrote:

 [...]
 There's std.algorithm.ordered which lets you write:
 
 	ordered(i, 4, n)
 
 which isn't too bad, it just needs to be promoted more so 
 that people are more aware of it.

 
 No short circuit though.

 [...]

 The docs don't say it, but it *does* in fact short-circuit if 
 you look at the implementation.

Yes, but after evaluating all the arguments :)

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Feb 24, 2022 at 09:51:09PM +0000, Stanislav Blinov via Digitalmars-d
wrote:
 On Thursday, 24 February 2022 at 21:26:04 UTC, H. S. Teoh wrote:
 On Thu, Feb 24, 2022 at 09:19:38PM +0000, Stanislav Blinov via
 Digitalmars-d wrote:
 On Thursday, 24 February 2022 at 21:05:49 UTC, H. S. Teoh wrote:

 [...]
 There's std.algorithm.ordered which lets you write:
 	ordered(i, 4, n)
 which isn't too bad, it just needs to be promoted more so >
 that people are more aware of it.


 
 No short circuit though.

 [...]
 
 The docs don't say it, but it *does* in fact short-circuit if you
 look at the implementation.

 
 Yes, but after evaluating all the arguments :)

Hmm, you're right.

Make the arguments lazy?  But then you have the  nogc problem.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

monkyyy <crazymonkyyy gmail.com> writes:

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


 So why doesn't D have it already ;-)

I agree there should be something to mean `1<n<3`; but further 
seems like a meme

there's a "in" keyword maybe `n in 1..3` or sometin

Paul Backus <snarwin gmail.com> writes:

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


 So why doesn't D have it already ;-)

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

Implementation is left as an exercise to the reader. :)