www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - How about `and` and `or` like in Python?

reply Murilo <murilomiranda92 hotmail.com> writes:
In Python the && operator is `and` just like the || operator is 
`or`. How about giving D this option? People could choose to use 
either of those forms. I am suggesting you create the `and` and 
`or` keywords to represent && and ||, respectively. That should 
make the code more readable.
Sep 30 2019
next sibling parent reply Elronnd <elronnd elronnd.net> writes:
Personally, I think this would make the code less readable; the 
current way creates more of a distinction between operators and 
operands.
Sep 30 2019
parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:

 Personally, I think this would make the code less readable; the 
 current way creates more of a distinction between operators and 
 operands.


But it could be an option, the current way would remain and this 
extra way would be added as an option.
Sep 30 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/30/2019 8:35 PM, Murilo wrote:

 On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:

 Personally, I think this would make the code less readable; the current way 
 creates more of a distinction between operators and operands.


 
 But it could be an option, the current way would remain and this extra way
would 
 be added as an option.


C++ does this. Nobody uses it.
Sep 30 2019
parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 1 October 2019 at 04:06:17 UTC, Walter Bright wrote:

 On 9/30/2019 8:35 PM, Murilo wrote:

 On Tuesday, 1 October 2019 at 02:25:11 UTC, Elronnd wrote:

 Personally, I think this would make the code less readable; 
 the current way creates more of a distinction between 
 operators and operands.


 
 But it could be an option, the current way would remain and 
 this extra way would be added as an option.


 C++ does this. Nobody uses it.


Maybe they do and you just don't see it. I would use it. I 
believe that code should be as close to natural language as 
possible, that mindset is what lead Python to being so successful.
Sep 30 2019
parent reply mipri <mipri minimaltype.com> writes:
On Tuesday, 1 October 2019 at 04:34:59 UTC, Murilo wrote:

 I believe that code should be as close to natural language as
 possible, that mindset is what lead Python to being so
 successful.


If your argument isn't that *Perl's* application of this mindset
contributed to Python overtaking Perl, then there are a lot Larry 
Wall
speeches about language that you may enjoy :-)

What you're doing here is a "wouldn't you like to be popular, like
that language over there?" kind of appeal. It is, paradoxically, 
an
extremely hard argument to succeed at making. The reason is that 
100k
variations of it will have already been heard by anyone you feel
comfortable making it to, so the argument has to be of an 
extremely
high standard to really be considered at all.
Sep 30 2019
parent Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 1 October 2019 at 05:15:47 UTC, mipri wrote:

 On Tuesday, 1 October 2019 at 04:34:59 UTC, Murilo wrote:

 I believe that code should be as close to natural language as
 possible, that mindset is what lead Python to being so
 successful.


 If your argument isn't that *Perl's* application of this mindset
 contributed to Python overtaking Perl, then there are a lot 
 Larry Wall
 speeches about language that you may enjoy :-)

 What you're doing here is a "wouldn't you like to be popular, 
 like
 that language over there?" kind of appeal. It is, 
 paradoxically, an
 extremely hard argument to succeed at making. The reason is 
 that 100k
 variations of it will have already been heard by anyone you feel
 comfortable making it to, so the argument has to be of an 
 extremely
 high standard to really be considered at all.


Man, you are making a whole philosophical speech about something 
tiny. I am just trying to explain that this would be good because 
it would make D richer since it would allow more readable code 
and give users more options.
Sep 30 2019
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-10-01 03:35:03 +0000, Murilo said:


 But it could be an option, the current way would remain and this extra 
 way would be added as an option.


Less syntactic options is better than more. Code is read much more 
frequent than written. Hence, I don't want to have to learn zillions of 
different ways to express the same thing.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 01 2019
parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 1 October 2019 at 15:26:57 UTC, Robert M. Münch wrote:

 On 2019-10-01 03:35:03 +0000, Murilo said:


 But it could be an option, the current way would remain and 
 this extra way would be added as an option.


 Less syntactic options is better than more. Code is read much 
 more frequent than written. Hence, I don't want to have to 
 learn zillions of different ways to express the same thing.


Well, okay, I get your point, but it would be only one add-on, it 
wouldn't make it messy, and besides, if you want minimalism then 
perhaps you should stick to C instead, there you have very few 
ways of writing code. And again, my idea would make it EASIER to 
read cause it would be closer to natural language.
Oct 01 2019
parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 1 October 2019 at 19:23:00 UTC, Murilo wrote:

 if you want minimalism then perhaps you should stick to C 
 instead, there you have very few ways of writing code. And 
 again, my idea would make it EASIER to read cause it would be 
 closer to natural language.


I used to program in a language (GML) that allowed both.
I always preferred `not`, `and` and `or` over the symbols `!`, 
`&&` and `||`.
That being said, adding the keywords when the symbols are already 
the standard is more harm than good.

It creates more bikeshedding / style-guides / arguments over 
which is the preferred way. There already is enough discussion 
about "options" for brace styles, tabs/spaces, 
snake_case/camelCase etc.

It also breaks existing code that uses these proposed keywords as 
identifiers.
For example in fluent asserts, this is no longer valid when `not` 
is a keyword: `x.should.not.be(null);`
Other examples:
- 
https://github.com/vibe-d/vibe.d/blob/c27f69dc9a17d969cbf394fa3b5947f8f7750ccf/web/vibe/web/auth.d#L342
- 
https://github.com/skoppe/spasm/blob/27717218bb64e10bab7a67511f87d4215bd2309c/source/spasm/ct.d#L868
- 
https://github.com/TurkeyMan/simd/blob/f04d4849dcd0b92b1d57b5a7974a9c686ff421e3/std/simd.d#L4516

Finally it opens the door for more "quality of life" synonyms, 
like `var` for `auto`, `boolean` for `bool`, angle brackets for 
template instantiations (yuck!), Java-like eponymous functions 
for constructors instead of `this()` etc.
Oct 01 2019
next sibling parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Tuesday, 1 October 2019 at 20:26:14 UTC, Dennis wrote:

 I used to program in a language (GML) that allowed both.
 I always preferred `not`, `and` and `or` over the symbols `!`, 
 `&&` and `||`.
 That being said, adding the keywords when the symbols are 
 already the standard is more harm than good.

 It creates more bikeshedding / style-guides / arguments over 
 which is the preferred way. There already is enough discussion 
 about "options" for brace styles, tabs/spaces, 
 snake_case/camelCase etc.

 It also breaks existing code that uses these proposed keywords 
 as identifiers.
 For example in fluent asserts, this is no longer valid when 
 `not` is a keyword: `x.should.not.be(null);`
 Other examples:


Alright. That makes sense. But what about making it capitalized 
as And, Or and Not, that will not conflict with keywords.
Oct 01 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 1 October 2019 at 20:34:19 UTC, Murilo wrote:


 Alright. That makes sense. But what about making it capitalized 
 as And, Or and Not, that will not conflict with keywords.


This has the same problem. You're introducing new keywords that 
will break any code using those words as identifiers.

What you're proposing has consequences. Aside from the potential 
for breakage, it adds complexity to the language. Opinions about 
improved readability and nicer aesthetics simply aren't strong 
enough to justify such a change (what gives your opinions more 
weight over those who disagree with you?).

Consider that when one person wanted to *remove* the keyword 
`body` as used in function contracts and replace it with another 
existing keyword, `do`, he wrote a DIP for it:

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md

And that's just to take something away from the language. You 
want to add something so that we'll have two ways of doing the 
same thing.

So a suggestion in the forums is not going to be the way to get 
this feature added. You'd need to write a DIP presenting a strong 
justification for the added complexity and the potential code 
breakage. And given the nature of the feature, I'd say you'd be 
fighting an uphill battle (meaning, I don't think there is a 
strong enough case to be made).
Oct 01 2019
next sibling parent Murilo <murilomiranda92 hotmail.com> writes:
On Wednesday, 2 October 2019 at 03:18:56 UTC, Mike Parker wrote:

 So a suggestion in the forums is not going to be the way to get 
 this feature added. You'd need to write a DIP presenting a 
 strong justification for the added complexity and the potential 
 code breakage. And given the nature of the feature, I'd say 
 you'd be fighting an uphill battle (meaning, I don't think 
 there is a strong enough case to be made).


Alright then.
Oct 01 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/1/2019 8:18 PM, Mike Parker wrote:

 So a suggestion in the forums is not going to be the way to get this feature 
 added. You'd need to write a DIP presenting a strong justification for the
added 
 complexity and the potential code breakage. And given the nature of the
feature, 
 I'd say you'd be fighting an uphill battle (meaning, I don't think there is a 
 strong enough case to be made).


As I mentioned, C++ has them:

https://en.cppreference.com/w/cpp/language/operator_alternative

https://www.reddit.com/r/cpp/comments/4h5lsb/why_arent_alternative_operators_more_common/

Adopting failed ideas from other languages is a pretty tough sell. One can 
always write a DIP, but I don't see a path for adoption for such a feature.
Oct 02 2019
parent Andrea Fontana <nospam example.com> writes:
On Wednesday, 2 October 2019 at 20:16:12 UTC, Walter Bright wrote:

 On 10/1/2019 8:18 PM, Mike Parker wrote:

 So a suggestion in the forums is not going to be the way to 
 get this feature added. You'd need to write a DIP presenting a 
 strong justification for the added complexity and the 
 potential code breakage. And given the nature of the feature, 
 I'd say you'd be fighting an uphill battle (meaning, I don't 
 think there is a strong enough case to be made).


 As I mentioned, C++ has them:

 https://en.cppreference.com/w/cpp/language/operator_alternative

 https://www.reddit.com/r/cpp/comments/4h5lsb/why_arent_alternative_operators_more_common/

 Adopting failed ideas from other languages is a pretty tough 
 sell. One can always write a DIP, but I don't see a path for 
 adoption for such a feature.


For some reason that syntax confuses me:

cout << true and false;

This prints out 1 in c++, but I read it as "cout << (true and 
false)".

Instead cout << true && false sounds to me like (cout << true) && 
false.
Oct 03 2019
prev sibling parent reply snow jhon <sportsdz25 gmail.com> writes:
On Tuesday, 1 October 2019 at 20:26:14 UTC, Dennis wrote:

 On Tuesday, 1 October 2019 at 19:23:00 UTC, Murilo wrote:

 [...]


 I used to program in a language (GML) that allowed both.
 I always preferred `not`, `and` and `or` over the symbols `!`, 
 `&&` and `||`.
 That being said, adding the keywords when the symbols are 
 already the standard is more harm than good.

 [...]


Personally, I think this would make the code less readable; the 
current way creates more of a distinction between operators and 
operands.
Oct 03 2019
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 3 October 2019 at 22:53:55 UTC, snow jhon wrote:

 Personally, I think this would make the code less readable; the 
 current way creates more of a distinction between operators and 
 operands.


With a syntax highlighter that makes them bold you don't have 
this problem.

Also, && and || are actually pretty exceptional operators. Most 
operators are simply functions mapping directly to hardware 
instructions with special symbol notation. In D they can be 
overloaded using functions opBinary or upUnary. && and || have 
lazy evaluation and therefor introduce control flow unlike 
functions whose parameters are evaluated first.

Zig is designed in such a way that all control flow happens 
through keywords. The bitwise and/or functions use the & and | 
symbols, but boolean and/or use the keywords [1]. (Also the 
ternary operator is just `if` and `else` forming an expression 
instead of a statement.)

This gives an actually useful distinction between keywords and 
symbols. But like I said, trying to change D on that aspect at 
this point is not useful.

[1] https://ziglang.org/documentation/0.5.0/#Operators
Oct 03 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/3/2019 4:35 PM, Dennis wrote:

 With a syntax highlighter that makes them bold you don't have this problem.


Language design that relies on a syntax highlighter is not good. An awful lot
of 
print media is still black-on-white, for example.
Oct 03 2019
parent Dennis <dkorpel gmail.com> writes:
On Friday, 4 October 2019 at 03:46:30 UTC, Walter Bright wrote:

 On 10/3/2019 4:35 PM, Dennis wrote:
 Language design that relies on a syntax highlighter is not 
 good. An awful lot of print media is still black-on-white, for 
 example.


Even on my typewriter I can make words bold, no color is needed. 
;)
Oct 03 2019
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 1 October 2019 at 00:47:57 UTC, Murilo wrote:

 In Python the && operator is `and` just like the || operator is 
 `or`. How about giving D this option? People could choose to 
 use either of those forms. I am suggesting you create the `and` 
 and `or` keywords to represent && and ||, respectively. That 
 should make the code more readable.


bool and(bool a, lazy bool b) { return a && b; }

if (cond1.and(cond2)) {
     // ...
}

Implementation of `or` is left as an exercise for the reader. :)
Oct 10 2019
parent Murilo <murilomiranda92 hotmail.com> writes:
On Thursday, 10 October 2019 at 18:01:36 UTC, Paul Backus wrote:

 On Tuesday, 1 October 2019 at 00:47:57 UTC, Murilo wrote:

 In Python the && operator is `and` just like the || operator 
 is `or`. How about giving D this option? People could choose 
 to use either of those forms. I am suggesting you create the 
 `and` and `or` keywords to represent && and ||, respectively. 
 That should make the code more readable.


 bool and(bool a, lazy bool b) { return a && b; }

 if (cond1.and(cond2)) {
     // ...
 }

 Implementation of `or` is left as an exercise for the reader. :)


Thanks.
Oct 10 2019