www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - foreach syntax

reply "Namespace" <rswhite4 googlemail.com> writes:


Means, why is it like
int[] arr = [1, 2, 3];

foreach (int val; arr) {

and not
foreach (int val in arr) {

which it is more intuitive.

I could give him no clever answer to, so maybe someone here knows 
the reasons.
Jun 29 2012
next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 06/29/2012 12:47 PM, Namespace wrote:

 
 Means, why is it like
 int[] arr = [1, 2, 3];
 
 foreach (int val; arr) {
 
 and not
 foreach (int val in arr) {
 
 which it is more intuitive.
 
 I could give him no clever answer to, so maybe someone here knows the
 reasons.
 
I suppose it is because the usual 'for' loop is a relative of 'foreach'. And there we (and the C world) uses ';'.
Jun 29 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Namespace:

In D you often omit the type: foreach (val; arr) { Using "in" is better for the human programmers. But D is largely designed to make D compilers too happy. I think Walter said that the semicolon was preferred because it simplifies the compiler/compilation a little. Bye, bearophile
Jun 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 01:01 PM, bearophile wrote:
 Namespace:

In D you often omit the type: foreach (val; arr) { Using "in" is better for the human programmers.
It is just as good as ';'.
 But D is largely
 designed to make D compilers too happy. I think Walter said that the
 semicolon was preferred because it simplifies the compiler/compilation a
 little.
It does not. Parsing the statements just about the same. In fact, only 2 lines in the DMD parser implementation need to be changed (slightly!) to implement the 'in' syntax instead.
Jun 29 2012
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Fri, 29 Jun 2012 12:47:28 +0200, Namespace wrote:


 
 Means, why is it like int[] arr = [1, 2, 3];
 
 foreach (int val; arr) {
 
 and not foreach (int val in arr) {
 
 which it is more intuitive.
 
 I could give him no clever answer to, so maybe someone here knows the
 reasons.
Because 1) "in" is a D keyword 2) D has even shorter syntax: foreach(val; arr) {} -- Dejan Lekic mailto:dejan.lekic(a)gmail.com http://dejan.lekic.org
Jun 29 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 12:47 PM, Namespace wrote:


 Means, why is it like
 int[] arr = [1, 2, 3];

 foreach (int val; arr) {
foreach(val; arr) {
 and not
 foreach (int val in arr) {

 which it is more intuitive.
 I could give him no clever answer to, so maybe someone here knows the
 reasons.
Just because. This does not matter.
Jun 29 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Just because. This does not matter.
Now and then I write foreach(x;y;data) or foreach(x,y,data) or foreach(x;y,data). "in" avoids some of those little mistakes. Bye, bearophile
Jun 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 04:16 PM, bearophile wrote:
 Timon Gehr:

 Just because. This does not matter.
Now and then I write foreach(x;y;data)
error: found ';' when expecting ')'
 or foreach(x,y,data) or
error: found ')' when expecting ';'
 foreach(x;y,data).
error: undefined identifier y
 "in" avoids some of those little mistakes.
foreach(x in y,data)
Jun 29 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 04:23 PM, Timon Gehr wrote:
 ...
 foreach(x;y,data).
error: undefined identifier y
BTW, it would certainly be better if this didn't actually pass the parser.
Jun 29 2012
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 foreach(x in y,data)
There is no way to avoid all possible mistakes, but it's easier to mistake a ";" for a ",", than mistake a "in" for a ",". languages because it's more readable than an arbitrary symbol like ";". Bye, bearophile
Jun 29 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 04:34 PM, bearophile wrote:
 Timon Gehr:

 foreach(x in y,data)
There is no way to avoid all possible mistakes, but it's easier to mistake a ";" for a ",", than mistake a "in" for a ",".
I don't think optimizing the grammar for error cases that are not even compilable code is worthwhile at all.

 languages because it's more readable
Probably it is used in those languages because it resembles mathematical notation, or let var in exp. I doubt there is anything deep behind it.
 than an arbitrary symbol like ";".
Probably, but when I read code, I don't read the ';', it is just a separator and helps orientation. Making separators 'readable' is imho a non-goal. But YMMV. Patching the parser so that it accepts both forms takes 20 seconds.
Jun 29 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, June 29, 2012 16:34:33 bearophile wrote:
 Timon Gehr:
 foreach(x in y,data)
There is no way to avoid all possible mistakes, but it's easier to mistake a ";" for a ",", than mistake a "in" for a ",". languages because it's more readable than an arbitrary symbol like ";".
And in Java, they use : rather than ; or in. This is completely subjective. I see _zero_ benefit in using in over ;. ; is nicely consistent with for, and is probably why foreach in D uses it. But regardless, it's purely a subjective Java picked what they picked. I really don't think that you can objectively argue that one is better than the other - not unless one is objectively easier to write the grammar for. Anything involving whether a person thinks in is or ; is easier to read or will cause fewer mistakes or whatnot is going to be purely subjective. - Jonathan M Davis
Jun 29 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, June 29, 2012 12:47:28 Namespace wrote:

 
 Means, why is it like
 int[] arr = [1, 2, 3];
 
 foreach (int val; arr) {
 
 and not
 foreach (int val in arr) {
 
 which it is more intuitive.
 
 I could give him no clever answer to, so maybe someone here knows
 the reasons.
Probably because for uses ; rather than in. But it's a purely subjective language design decision. Walter could have used : like Java does, and it would have worked just as well. He decided to go with ;. On the whole, we was anything AFAIK. Lots of stuff like this is going to vary from language to language, and often the decisions are arbitrary and have nothing to do with what other languages did or are based completely on the lanugage designer's personal preferences. If there's no technical reason for going with one over the other (and I'm not aware of one in this case), then it's up to the language designer to make a choice on it which is going to be completely subjective. - Jonathan M Davis
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
It wasn't my intention to start a syntax war. :D
But i must agree, that "in" is a lot more readable as ";". Event 
":" ist more readable as ";". But i just would know the real 
reason to this decision. Tanks to all. :)
But why correct a few guys here my code?
foreach (int val; is the same as foreach(val; except that i like 
to write which type "val" is. Is that against the D nature or 
what?

P.S.: Which line must be changed to allow the "in2 syntax?
Just out of pure interest. Thanks.
Jun 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 06:09 PM, Namespace wrote:
 It wasn't my intention to start a syntax war. :D
 But i must agree, that "in" is a lot more readable as ";". Event ":" ist
 more readable as ";". But i just would know the real reason to this
 decision. Tanks to all. :)
 But why correct a few guys here my code?
It was more of a suggestion than a correction.
 foreach (int val; is the same as foreach(val; except that i like to
 write which type "val" is. Is that against the D nature or what?
It is redundant.
 P.S.: Which line must be changed to allow the "in2 syntax?
 Just out of pure interest. Thanks.
Search for TOKforeach in parse.c and change the TOKsemicolon's around there to TOKin's. If you want to allow both, that should be straightforward as well.
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 It is redundant.
But informative.
 Search for TOKforeach in parse.c and change the TOKsemicolon's 
 around there to TOKin's. If you want to allow both, that should 
 be
 straightforward as well.
I will try.
Jun 29 2012
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
You mean line 3817 change to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value 
== TOKin) ?
But i have to rebuild dmd or not? I'm a windows user and I never 
build dmd on my own.
Jun 29 2012
parent David <d dav1d.de> writes:
Am 29.06.2012 18:23, schrieb Namespace:
 You mean line 3817 change to
 if (t->value == TOKcomma || t->value == TOKsemicolon || t->value ==
 TOKin) ?
 But i have to rebuild dmd or not? I'm a windows user and I never build
 dmd on my own.
Yes, you have to recompile DMD
Jun 29 2012
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
You mean just change line 3817 to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value 
== TOKin) ?
But know i have to rebuild dmd (i use windows), and i never did 
this before. :/
Jun 29 2012
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 29 June 2012 at 16:27:23 UTC, Namespace wrote:
 You mean just change line 3817 to
 if (t->value == TOKcomma || t->value == TOKsemicolon || 
 t->value == TOKin) ?
 But know i have to rebuild dmd (i use windows), and i never did 
 this before. :/
Which is easy. I write a guide as soon as time permits.
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Which is easy.
Even on Windows? :O
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
 Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the compiler still says "found 'in' when expecting ';'!" if i try to write foreach (val in vals) {. Have i edit the wrong line in paste.c or fails my build?
Jun 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 07:47 PM, Namespace wrote:
 On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
 Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the compiler still says "found 'in' when expecting ';'!" if i try to write foreach (val in vals) {. Have i edit the wrong line in paste.c or fails my build?
You have to edit both relevant lines.
Jun 29 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 06:27 PM, Namespace wrote:
 You mean just change line 3817 to
 if (t->value == TOKcomma || t->value == TOKsemicolon || t->value ==
 TOKin) ?
 But know i have to rebuild dmd (i use windows), and i never did this
 before. :/
You'll also have to change the line that says expect(TOKsemicolon);
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 You'll also have to change the line that says 
 expect(TOKsemicolon);
In what? comment out?
Jun 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 07:50 PM, Namespace wrote:
 You'll also have to change the line that says expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that if(token.value == TOKin) nextToken(); else expect(TOKsemicolon); might get you going.
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote:
 On 06/29/2012 07:50 PM, Namespace wrote:
 You'll also have to change the line that says 
 expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that if(token.value == TOKin) nextToken(); else expect(TOKsemicolon); might get you going.
I think i'm to stupid for that, sry. I comment out "check" (just for testing) but then i get much more errors if i try to compile "foreach (val in vals) {".
Jun 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 08:04 PM, Namespace wrote:
 On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote:
 On 06/29/2012 07:50 PM, Namespace wrote:
 You'll also have to change the line that says expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that if(token.value == TOKin) nextToken(); else expect(TOKsemicolon); might get you going.
I think i'm to stupid for that, sry.
My bad: Replacing the line with the following, together with the other change you made, works: if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 My bad:

 Replacing the line with the following, together with the other 
 change you made, works:

 if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Impressive, thanks a lot, sometimes I'm a bit stupid. :) Last question: It works fine, but i'm getting now "DMD v2.059 DEBUG" if i compile. Do I need a special flag by recompiling?
Jun 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 08:18 PM, Namespace wrote:
 My bad:

 Replacing the line with the following, together with the other change
 you made, works:

 if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Impressive, thanks a lot, sometimes I'm a bit stupid. :) Last question: It works fine, but i'm getting now "DMD v2.059 DEBUG" if i compile. Do I need a special flag by recompiling?
I don't have a windows system handy, but you could try the following: make -fwin32.mak release
Jun 29 2012
parent "Namespace" <rswhite4 googlemail.com> writes:
 make -fwin32.mak release
That simple... :) Many thanks!
Jun 29 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 29, 2012 18:16:23 Namespace wrote:
 It is redundant.
But informative.
It's very common in D to not put the type unless it's absolutely necessary (e.g. use auto everywhere). This can be both good and bad for code readability and maintenance, but it's particularly useful with generic code, which is generally promoted quite heavily. So, I think that you'll find that most of the people around here generally don't explicitly use the type unless they need to (though there's always someone who's an exception). - Jonathan M Davis
Jun 29 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
But there is no overhead or something else _if_ i put the type, 
or?
Jun 29 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 09:51 PM, Namespace wrote:
 But there is no overhead or something else _if_ i put the type, or?
There is a slight typing and compilation overhead. Nothing significant.
Jun 29 2012
parent reply "Roman D. Boiko" <rb d-coding.com> writes:
On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote:
 On 06/29/2012 09:51 PM, Namespace wrote:
 But there is no overhead or something else _if_ i put the 
 type, or?
There is a slight typing and compilation overhead. Nothing significant.
You missed a slight reading overhead.
Jun 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2012 10:02 PM, Roman D. Boiko wrote:
 On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote:
 On 06/29/2012 09:51 PM, Namespace wrote:
 But there is no overhead or something else _if_ i put the type, or?
There is a slight typing and compilation overhead. Nothing significant.
You missed a slight reading overhead.
Good catch.
Jun 29 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 29, 2012 21:51:20 Namespace wrote:
 But there is no overhead or something else _if_ i put the type,
 or?
No. It's like auto. The type is inferred. It's all statically typed and strongly typed. It's not like it figures out the type at runtime or anything like that. It's all done at compile time. It's just like C++11's auto. It makes refactoring code a lot easier, and it makes generic code a _lot_ easier to write. Without auto, std.algorithm would pretty much be impossible (you _could_ do it, but it would be so disgusting that no one would want to use it, because all of those compound range types get truly hideous if you actually look at the types themselves - voldemort types have reduced that problem, but they'd be impossible without auto anyway). It's up to you whether you want to put types explicitly or use let them be inferred with auto or in foreach loops, but it's more or less common practice at this point to use type inferrence very heavily and to avoid using types explicitly except when you need to. - Jonathan M Davis
Jun 29 2012