www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Maybe we don't need foreach ;-)

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Just like some people have said, you can do everything with 'for'.
Well, actually maybe you can.  It occurred to me that foreach and for 
really don't clash.  One requires two semicolons, the other only one. 
So instead of a foreach we could have had

   for(a; aggregate)
   {

   }


or if the keyword 'in' had been used for the new construct instead of 
borrowing from c's ; syntax it would be:

   for(a in aggregate)
   {
      ...
   }

which could quite peacefully coexist with good-ole

   for (int i=0; i<10; i++)
   {
   }

Oh well.  Too much momentum behind foreach and foreach_reverse now, I 
suppose, to make such a simplification.

--bb
Oct 30 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Just like some people have said, you can do everything with 'for'.
 Well, actually maybe you can.  It occurred to me that foreach and for 
 really don't clash.  One requires two semicolons, the other only one. So 
 instead of a foreach we could have had
 
   for(a; aggregate)
   {
 
   }


That looks like a syntax error for one used to for loops.


 or if the keyword 'in' had been used for the new construct instead of 
 borrowing from c's ; syntax it would be:
 
   for(a in aggregate)
   {
      ...
   }


'in' is already an operator, so that wouldn't work.


 which could quite peacefully coexist with good-ole
 
   for (int i=0; i<10; i++)
   {
   }
 
 Oh well.  Too much momentum behind foreach and foreach_reverse now, I 
 suppose, to make such a simplification.


foreach is a fairly well understood term, I think it needs less 
explanation than a variant on for.
Oct 30 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Just like some people have said, you can do everything with 'for'.
 Well, actually maybe you can.  It occurred to me that foreach and for 
 really don't clash.  One requires two semicolons, the other only one. 
 So instead of a foreach we could have had

   for(a; aggregate)
   {

   }


 
 That looks like a syntax error for one used to for loops.


For one used to C for loops, yes.  But Python for loops look like
   for a in aggregate: ...
Bash for loops look like
   for f in list; do ... done

There is certainly precedent for using 'for' synonymously with 'for each'.


 or if the keyword 'in' had been used for the new construct instead of 
 borrowing from c's ; syntax it would be:

   for(a in aggregate)
   {
      ...
   }


 
 'in' is already an operator, so that wouldn't work.


It already has multiple duties as a storage type, so that alone 
shouldn't be an issue.
But I suppose you're right that it won't work here since a standard for 
loop can start with an Expression, which can contain an 'in'.  So this 
would require arbitrary lookahead to see if there are any ';''s coming 
or not.

Anyway, it wouldn't be a problem in a foreach :-).  foreach can only 
start with ForeachTypeList so there would be no problems with:

    foreach(a in aggregate) { }

as far as I can tell.


 which could quite peacefully coexist with good-ole

   for (int i=0; i<10; i++)
   {
   }

 Oh well.  Too much momentum behind foreach and foreach_reverse now, I 
 suppose, to make such a simplification.


 
 foreach is a fairly well understood term, I think it needs less 
 explanation than a variant on for.


Perhaps.  But we're talking about epsilon vs 2*epsilon in terms of the 
amount of explanation required.

One thing foreach has going for it is that it makes it feasible to 
replace the ';' with the 'in' keyword.  :-)

--bb
Oct 30 2006
parent Burton Radons <burton-radons smocky.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Just like some people have said, you can do everything with 'for'.
 Well, actually maybe you can.  It occurred to me that foreach and for 
 really don't clash.  One requires two semicolons, the other only one. 
 So instead of a foreach we could have had

   for(a; aggregate)
   {

   }


 That looks like a syntax error for one used to for loops.


 
 For one used to C for loops, yes.  But Python for loops look like
   for a in aggregate: ...
 Bash for loops look like
   for f in list; do ... done
 
 There is certainly precedent for using 'for' synonymously with 'for each'.


Who is more likely to move to D - a C/C++ programmer who also knows 
Python/Bash, or a dedicated Python or Bash programmer?


 or if the keyword 'in' had been used for the new construct instead of 
 borrowing from c's ; syntax it would be:

   for(a in aggregate)
   {
      ...
   }


 'in' is already an operator, so that wouldn't work.


 
 It already has multiple duties as a storage type, so that alone 
 shouldn't be an issue.
 But I suppose you're right that it won't work here since a standard for 
 loop can start with an Expression, which can contain an 'in'.  So this 
 would require arbitrary lookahead to see if there are any ';''s coming 
 or not.


Arbitrary lookahead is no problem for D (it has to do this anyway, a 
lot, and this is a good thing as it's more important for a language to 
be comprehensible to the user, and minimise redundant information, than 
it is for it to be simple to parse), and is makes logical sense, as it 
iterates over all "a" which are in "aggregate". For example:

     where (uint a; a < 100) // Iterate from 0 to 99.
     where (a; a >= 0 && a < 100 && a % 2) // Iterate over every odd 
value from 0 to 99.
     where (a; a in list1 && a in list2) // Set intersection.
     where (a; a in list1 || a in list2) // Set union.
     where (a; a in list1 && a !in list2) // Set difference.

     auto list3 = where (a; a in list1 && a in list2); // Wee!

This is pretty easy to do terribly, somewhat harder to do usefully, very 
hard to do intelligently, and incomprehensibly hard to do at peak 
optimisability in all cases. I'm not proposing it as a D feature, it's 
very much not in its style and it's something you'd spend twenty years 
progressively optimising, but it would be fun to have these kinds of 
advanced data-processing features in a fast language. So long as we're 
in fantasy-land:

     where (a; 0 <= a < 100)

Ah, that's better. C's idea that logical operations belong on the same 
continuum as equations is so very, very 60s. And if we're no longer 
working with such outdated logic:

     where (a; a in (list1 && list2));

Makes sense to me.
Nov 01 2006
prev sibling next sibling parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
I don't see much reason to change the syntax here, since:
  - it provides no generalizations/abstractions
  - it only saves 4 keys of typing
  - it isn't easier to read; perhaps even *harder* (you don't know 
whether it is a custom iterator or a 'normal' for loop)
  - Walter's right: it could increase bugs, such as:

      for (char[] key, char[] value; aggregate)

         which looks similar to

      for (char[] key; char[] value; aggregate)

Cheers,

Reiner
Oct 30 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Reiner Pope wrote:

 I don't see much reason to change the syntax here, since:
  - it provides no generalizations/abstractions


It generalizes 'for'.


  - it only saves 4 keys of typing


It's more about saving a keyword in the grammar than saving typing.


  - it isn't easier to read; perhaps even *harder* (you don't know 
 whether it is a custom iterator or a 'normal' for loop)


Yeh, that's sort of true, but 90% of regular for loops have a ++ or -- 
or += or .next() in them at the end that make them pretty easy to 
recognize as regular for loops.  Any for loop that doesn't fit that 
pattern already takes some scrutiny to figure out.


  - Walter's right: it could increase bugs, such as:
 
      for (char[] key, char[] value; aggregate)
 
         which looks similar to
 
      for (char[] key; char[] value; aggregate)


That'd be a syntax error.   You cannot declare variables in the second 
clause of a standard for-loop.  You can only have an Expression there.

But yeh, I'm sure you can cook up some example where you change one 
comma to a semicolon and both are legal.

Anyway, the real answer is trailing delegates.  This wasn't a serious 
proposal for change, more just musing on what could have been.  foreach 
didn't really have to be a keyword, I don't think, that's the only 
observation I was trying to make.

--bb
Oct 30 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 But yeh, I'm sure you can cook up some example where you change one 
 comma to a semicolon and both are legal.


	for (a, b; c)
	for (a; b; c)

Not only do they look very, very similar, it is not at all obvious which 
one was intended.
Oct 30 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 But yeh, I'm sure you can cook up some example where you change one 
 comma to a semicolon and both are legal.


 
     for (a, b; c)
     for (a; b; c)
 
 Not only do they look very, very similar, it is not at all obvious which 
 one was intended.


Assuming you mean literally a b and c, it's pretty clear it's got to be 
a foreach that was intended.  There's no reason to stick a variable in 
either the first or last clause of a standard for.

Here's a example where the intent really isn't obvious:

    for (int a; b;)
    for (int a; b)

Anyway, given that
* I myself have been guilty of using ',' where I meant ';' in for loops,
* 'in' can't be used in place of ';' due to syntactical ambiguities,

I agree that it's safer and better to have foreach separate.

--bb
Oct 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Assuming you mean literally a b and c, it's pretty clear it's got to be 
 a foreach that was intended.  There's no reason to stick a variable in 
 either the first or last clause of a standard for.


There is if a and b are function names.



 Here's a example where the intent really isn't obvious:
 
    for (int a; b;)
    for (int a; b)
 
 Anyway, given that
 * I myself have been guilty of using ',' where I meant ';' in for loops,
 * 'in' can't be used in place of ';' due to syntactical ambiguities,
 
 I agree that it's safer and better to have foreach separate.
 
 --bb
Oct 30 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Assuming you mean literally a b and c, it's pretty clear it's got to 
 be a foreach that was intended.  There's no reason to stick a variable 
 in either the first or last clause of a standard for.


 
 There is if a and b are function names.


I see.  I didn't realize this property stuff extended to plain functions 
too.  I would be strongly inclined to wedgie anyone who made extensive 
use of that feature.  :-)

--bb
Oct 30 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 Reiner Pope wrote:

 I don't see much reason to change the syntax here, since:
  - it provides no generalizations/abstractions


 
 It generalizes 'for'.
 


No it doesn't. It provides no semantic generalization/orthogonality *as 
well as* no syntactic generalization/orthogonality either. If you think 
of the D grammar, the 'foreach' rule is removed, but another, similar 
one is added to the 'for' rule alternatives.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 31 2006
prev sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
I got so used to foreach in D, I've just ported it to C ;)

namespace D {
template <typename T, int S>
inline size_t length( T (&a)[S] ) { return S; }
// Add overloads for your own containers
}

#define foreach(ELEMENT,ARRAY) \
  for(size_t __L=D::length(ARRAY),__B=0,__I=0; !__B && __I<__L; 
assert(__L==D::length(ARRAY)), ++__I ) \
    if (__B = 1) \
      for(ELEMENT = ARRAY[__I]; __B; __B=0) // a break must make the main 
loop stop

Don't get too scared; Microsoft's compiler does a great job optimizing that 
loop. In fact, if you don't use 'break', the second loop will disappear 
completely. I haven't checked the generated code on other compilers yet.

You use it like this (yes, it's C):

int nums[] = {1,2,3,4};
foreach(int i,nums) { }
foreach(int &i,nums) { i=2; }

L.
Oct 30 2006
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Lionello Lunesu wrote:

 I got so used to foreach in D, I've just ported it to C ;)
 
 namespace D {
 template <typename T, int S>
 inline size_t length( T (&a)[S] ) { return S; }
 // Add overloads for your own containers
 }
 
 #define foreach(ELEMENT,ARRAY) \
   for(size_t __L=D::length(ARRAY),__B=0,__I=0; !__B && __I<__L; 
 assert(__L==D::length(ARRAY)), ++__I ) \
     if (__B = 1) \
       for(ELEMENT = ARRAY[__I]; __B; __B=0) // a break must make the main 
 loop stop


I think you have a dangling-else bug here:

	if (whatever)
		foreach(elt, arr) { something(); }
	else
		somethingelse();

What happens in this code? It looks like somethingelse() will be 
executed if whatever evaluates to false, but IIRC the 'else' clause will 
bind to the 'if' you have in your macro. Since that one never evaluates 
to false, somethingelse() will never be called here.

I haven't tried it though, this was just from looking at it.
Also, this won't manifest itself if you always use braces after 'if's so 
this may be hard to spot the one time you forget :).
Oct 31 2006
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Frits van Bommel wrote:

 Lionello Lunesu wrote:

 I got so used to foreach in D, I've just ported it to C ;)

 namespace D {
 template <typename T, int S>
 inline size_t length( T (&a)[S] ) { return S; }
 // Add overloads for your own containers
 }

 #define foreach(ELEMENT,ARRAY) \
   for(size_t __L=D::length(ARRAY),__B=0,__I=0; !__B && __I<__L; 
 assert(__L==D::length(ARRAY)), ++__I ) \
     if (__B = 1) \
       for(ELEMENT = ARRAY[__I]; __B; __B=0) // a break must make the 
 main loop stop


 
 I think you have a dangling-else bug here:
 
     if (whatever)
         foreach(elt, arr) { something(); }
     else
         somethingelse();
 
 What happens in this code? It looks like somethingelse() will be 
 executed if whatever evaluates to false, but IIRC the 'else' clause will 
 bind to the 'if' you have in your macro. Since that one never evaluates 
 to false, somethingelse() will never be called here.
 
 I haven't tried it though, this was just from looking at it.
 Also, this won't manifest itself if you always use braces after 'if's so 
 this may be hard to spot the one time you forget :).


Good one, easily solvable though, by inverting __B and using "if () {} 
else for...".. Thanks!

L.
Oct 31 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 I got so used to foreach in D, I've just ported it to C ;)


I believe Eric Niebler wrote one too for C++ using preprocessor 
wizardry. I've never been able to figure out how it worked <g>.
Oct 31 2006