www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Missing python-like chaining in D

reply 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 ;-)
Feb 21
next sibling parent reply 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.
Feb 21
parent reply 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.
Feb 22
parent =?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
Feb 22
prev sibling next sibling parent reply 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.
Feb 21
next sibling parent 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.
Feb 21
prev sibling next sibling parent reply 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();
Feb 21
next sibling parent 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.
Feb 21
prev sibling next sibling parent 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.
Feb 21
prev sibling parent reply =?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
Feb 21
parent reply 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```
Feb 22
parent reply 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
Feb 25
parent 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...
Feb 26
prev sibling next sibling parent reply 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).
Feb 21
parent reply 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.
Feb 22
next sibling parent reply 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
Feb 22
parent reply 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.
Feb 22
next sibling parent reply 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
Feb 22
next sibling parent "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.
Feb 22
prev sibling parent reply 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.
Feb 22
parent 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.)
Feb 22
prev sibling parent reply 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.
Feb 23
parent reply 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?
Feb 23
next sibling parent reply 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.
Feb 23
parent 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.)
Feb 23
prev sibling parent reply 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.
Feb 23
parent reply 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.
Feb 23
parent 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.
Feb 23
prev sibling next sibling parent reply 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.
Feb 22
parent reply 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?..
Feb 22
next sibling parent reply 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.
Feb 22
parent reply 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.
Feb 22
next sibling parent reply 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....
Feb 22
parent 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.
Feb 22
prev sibling parent 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.
Feb 22
prev sibling next sibling parent reply 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.
Feb 22
parent reply 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.
Feb 22
next sibling parent reply 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
Feb 23
parent reply 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.
Feb 23
parent 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' ;-)
Feb 23
prev sibling parent 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
Feb 23
prev sibling parent 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??
Feb 22
prev sibling parent 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!
Feb 22
prev sibling parent reply 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?
Feb 22
next sibling parent reply 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 ```
Feb 22
parent 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!
Feb 22
prev sibling parent 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.
Feb 22
prev sibling next sibling parent reply 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
Feb 23
parent reply 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 ;-)
Feb 23
parent reply 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.
Feb 24
parent reply 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.
Feb 24
parent reply "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.
Feb 24
parent reply 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.
Feb 24
parent reply "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.
Feb 24
parent reply 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 :)
Feb 24
parent "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
Feb 24
prev sibling next sibling parent 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
Feb 24
prev sibling parent 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. :)
Feb 26