www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Differentiate const flavors using CASE?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Here's a random thought:
What about const vs CONST?
The upcase version obviously being the more const of the two.
The original proposal played with punctuation, and we've talked plenty 
about spelling, but we haven't talked about playing with case.  It would 
be an odd-ball among keywords, admittedly, but if you asked 100 people 
which of 'const' and 'CONST' was the most constant you'd probably get 
100 votes for 'CONST'.  And he could become good friends with 
foreach_reverse, the other odd-ball keyword who is disparaged by the 
other kids because of his obesity and the big staple in his belly button.

---bb
Mar 21 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked plenty 
 about spelling, but we haven't talked about playing with case.  It would 
 be an odd-ball among keywords, admittedly, but if you asked 100 people 
 which of 'const' and 'CONST' was the most constant you'd probably get 
 100 votes for 'CONST'.  And he could become good friends with 
 foreach_reverse, the other odd-ball keyword who is disparaged by the 
 other kids because of his obesity and the big staple in his belly button.



LOL ... Now that *is* funny.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/03/2007 9:32:04 AM
Mar 21 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:
 

 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked plenty 
 about spelling, but we haven't talked about playing with case.  It would 
 be an odd-ball among keywords, admittedly, but if you asked 100 people 
 which of 'const' and 'CONST' was the most constant you'd probably get 
 100 votes for 'CONST'.  And he could become good friends with 
 foreach_reverse, the other odd-ball keyword who is disparaged by the 
 other kids because of his obesity and the big staple in his belly button.



 LOL ... Now that *is* funny.



Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
{ ... }. The keyword(extra) syntax is definitely becoming a D signature 
syntax.


Andrei
Mar 21 2007
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 
 Andrei



What do you call that little non-keyword in parens when you refer to it 
in your parsing code? If it's not a keyword or an operator or an 
identifier, how do you refer to it?

Just curious.

--benji
Mar 21 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball keyword 
 who is disparaged by the other kids because of his obesity and the 
 big staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 What do you call that little non-keyword in parens when you refer to it 
 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?
 
 Just curious.



Some call it "contextual keyword".

Andrei
Mar 21 2007
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 21 Mar 2007 17:33:00 -0700, Benji Smith wrote:


 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 Andrei



 What do you call that little non-keyword in parens when you refer to it 
 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?
 
 Just curious.



An adornment/ornamentation/embellishment maybe? 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/03/2007 11:45:23 AM
Mar 21 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Derek Parnell wrote:

 On Wed, 21 Mar 2007 17:33:00 -0700, Benji Smith wrote:
 

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.






 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.

 Andrei



 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?

 Just curious.



 An adornment/ornamentation/embellishment maybe? 



We could always call them "ruby keywords"[1], and just annoy the hell
out of ruby users >:)

	-- Daniel

[1] The phrase being stolen from the idea of "ruby text": small
additional text written beside Japanese kanji which helps disambiguate
them; pretty much exactly what these things are doing :)

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 21 2007
prev sibling next sibling parent "David B. Held" <dheld codelogicconsulting.com> writes:
Derek Parnell wrote:

 On Wed, 21 Mar 2007 17:33:00 -0700, Benji Smith wrote:
 

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.






 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.

 Andrei



 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?

 Just curious.



 An adornment/ornamentation/embellishment maybe? 



Or, to annoy people who hate Microsoft's "musical" languages, we could 
call them "grace notes".

Dave
Mar 21 2007
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Derek Parnell wrote:

 On Wed, 21 Mar 2007 17:33:00 -0700, Benji Smith wrote:
 

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.






 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.

 Andrei



 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?

 Just curious.



 An adornment/ornamentation/embellishment maybe? 
 



I've always thought of them as "identifier/identity parameters"... but I like
"adornment" 
better.

-- Chris Nicholson-Sauls
Mar 22 2007
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball keyword 
 who is disparaged by the other kids because of his obesity and the 
 big staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 What do you call that little non-keyword in parens when you refer to it 
 in your parsing code? If it's not a keyword or an operator or an 
 identifier, how do you refer to it?
 
 Just curious.



I've always referred to it as a "modifier", almost like how template parameters
"modify" the shape/contents/behavior of 
the enclosing type.  Taking into consideration Andrei's suggestion to your
post, perhaps "contextual modifier" might be 
more appropriate?

-- 
- EricAnderton at yahoo
Mar 22 2007
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Andrei Alexandrescu (See Website For Email) escribió:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 
 Andrei



I've actually started to like foreach_reverse. I most of the time 
program in Java and, you know, Java 1.5 has foreach:

foreach(String s : words) {
}

I use it very widely, trying not to do a loop with a counter to avoid 
typing more and to avoid bugs. But then I had to write an algorithm that 
iterated the array backwards, and if I only had foreach_reverse the code 
would have been clean and nice...

Of course, sometimes you have to iterate other ways, but foward and 
backwards are way too common.
Mar 21 2007
parent Tom <tom nospam.com> writes:
Ary Manzana escribió:

 Andrei Alexandrescu (See Website For Email) escribió:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball keyword 
 who is disparaged by the other kids because of his obesity and the 
 big staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 I've actually started to like foreach_reverse. I most of the time 
 program in Java and, you know, Java 1.5 has foreach:
 
 foreach(String s : words) {
 }



Actually, I think it is:

for (String s: words) {
}

So it was that they didn't add the 'foreach' keyword to preserve 
backward compatibility... which I find pretty ridiculous (but I could be 
wrong) :)

--
Tom;
Mar 21 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 
 Andrei



//Using your other suggestion:
foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) (item3 
; collection3)
{

}

Its starting to get hard and harder to read IMO.

Although perhaps the reverse could be come sort of iterator mechanism. 
You could define what order items are visited.  I mean, reverse would 
not be a keyword at all and would exist in some library.  Although I'm 
not sure how it would be implemented, and it may defeat the purpose of 
foreach_reverse being optimal.

Just a thought.
Mar 21 2007
parent reply kris <foo bar.com> writes:
janderson wrote:

 Andrei Alexandrescu (See Website For Email) wrote:
 

 Derek Parnell wrote:


 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball keyword 
 who is disparaged by the other kids because of his obesity and the 
 big staple in his belly button.




 LOL ... Now that *is* funny.




 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 
 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) (item3 
 ; collection3)
 {
 
 }
 
 Its starting to get hard and harder to read IMO.
 
 Although perhaps the reverse could be come sort of iterator mechanism. 
 You could define what order items are visited.  I mean, reverse would 
 not be a keyword at all and would exist in some library.  Although I'm 
 not sure how it would be implemented, and it may defeat the purpose of 
 foreach_reverse being optimal.
 
 Just a thought.



shouldn't this perhaps be something like:

foreach (item; collection) (item2; x->GetColection(b))(item3; 
collection3.reverse)
{

}


Now you can select a direction on the each container?

Naturally, this would avoid performing a copy of the content, and the 
basic approach is quite easy to handle via a struct containing an 
opApply(). It would open the door to alternate iteration approaches 
also, such as skipping entries, merging, or whatever.

Tango does something vaguely like this for the text-iterators in 
tango.text.Util
Mar 21 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
kris wrote:

 janderson wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Yah :o). Speaking of foreach_reverse, probably it would be wise to
 lobby Walter to deprecate it in favor of foreach(reverse) (item ;
 collection) { ... }. The keyword(extra) syntax is definitely becoming
 a D signature syntax.


 Andrei




 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b))
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator mechanism.
 You could define what order items are visited.  I mean, reverse would
 not be a keyword at all and would exist in some library.  Although I'm
 not sure how it would be implemented, and it may defeat the purpose of
 foreach_reverse being optimal.

 Just a thought.



 shouldn't this perhaps be something like:
 
 foreach (item; collection) (item2; x->GetColection(b))(item3;
 collection3.reverse)
 {
 
 }
 
 
 Now you can select a direction on the each container?
 
 Naturally, this would avoid performing a copy of the content, and the
 basic approach is quite easy to handle via a struct containing an
 opApply(). It would open the door to alternate iteration approaches
 also, such as skipping entries, merging, or whatever.
 
 Tango does something vaguely like this for the text-iterators in
 tango.text.Util



What if collection3 is a 40 MB array?

The nice thing about foreach_reverse is that it doesn't require any
transformations on the data.  The bad thing is... it's ugly :P  That,
and once we get parallel iteration, we won't be able to go forward on
one aggregate, and backwards on the other.

Possibilities:

foreach (forward,forward,reverse) (item1; col1) (item2; x.GetCol(b))
	(item3; col3)
{
    // ...
}

foreach (item1; col) (item2; x.GetCol(b)) (reverse)(item3; col3)
{
    // ...
}

foreach (item1; col) (item2; x.GetCol(b)) (reverse item3; col3)
{
    // ...
}

In any case, I like the idea of having foreach(scheme), where "scheme"
could be "forward", "reverse", "depthfirst", "topological", whatever.
And if D2.0 gets generators as well... well, I can't think of any other
procedural language that could even come close to touching us :)

	-- Daniel

P.S. One last thought:

class Heap
{
    int opApply(...) { ... dg(v); ... }
    int opApplyReverse(...) { ... }
    int opApply_depthfirst(...) { ... }
    int opApply_sorted(...) { ... }

    // Wouldn't it be cool if the above could be written as...

    foreach(...) { foreach( v ; this.backing ) yield v; }
    foreach(reverse)(...) { ... }
    foreach(depthfirst)(...) { ... }
    foreach(sorted)(...) { ... }
}

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 21 2007
next sibling parent reply kris <foo bar.com> writes:
Daniel Keep wrote:

 
 kris wrote:
 

janderson wrote:


Andrei Alexandrescu (See Website For Email) wrote:


Yah :o). Speaking of foreach_reverse, probably it would be wise to
lobby Walter to deprecate it in favor of foreach(reverse) (item ;
collection) { ... }. The keyword(extra) syntax is definitely becoming
a D signature syntax.


Andrei




//Using your other suggestion:
foreach(reverse) (item ; collection) (item2 ; x->GetColection(b))
(item3 ; collection3)
{

}

Its starting to get hard and harder to read IMO.

Although perhaps the reverse could be come sort of iterator mechanism.
You could define what order items are visited.  I mean, reverse would
not be a keyword at all and would exist in some library.  Although I'm
not sure how it would be implemented, and it may defeat the purpose of
foreach_reverse being optimal.

Just a thought.



shouldn't this perhaps be something like:

foreach (item; collection) (item2; x->GetColection(b))(item3;
collection3.reverse)
{

}


Now you can select a direction on the each container?

Naturally, this would avoid performing a copy of the content, and the
basic approach is quite easy to handle via a struct containing an
opApply(). It would open the door to alternate iteration approaches
also, such as skipping entries, merging, or whatever.

Tango does something vaguely like this for the text-iterators in
tango.text.Util



 
 What if collection3 is a 40 MB array?
 
 The nice thing about foreach_reverse is that it doesn't require any
 transformations on the data.  



I didn't suggest transformation at all :) Merely a mean of satisfying 
opApply that happens to go backwards instead (or some other pattern).

Please, take a peek at tango.text.Util ... methods lines(), delimiters() 
and patterns() are examples of what I'm getting at. That particular 
approach can easily be adapted for any kind of container
Mar 21 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
kris wrote:

 Daniel Keep wrote:

 kris wrote:


 janderson wrote:


 Andrei Alexandrescu (See Website For Email) wrote:


 Yah :o). Speaking of foreach_reverse, probably it would be wise to
 lobby Walter to deprecate it in favor of foreach(reverse) (item ;
 collection) { ... }. The keyword(extra) syntax is definitely becoming
 a D signature syntax.


 Andrei




 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b))
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator mechanism.
 You could define what order items are visited.  I mean, reverse would
 not be a keyword at all and would exist in some library.  Although I'm
 not sure how it would be implemented, and it may defeat the purpose of
 foreach_reverse being optimal.

 Just a thought.



 shouldn't this perhaps be something like:

 foreach (item; collection) (item2; x->GetColection(b))(item3;
 collection3.reverse)
 {

 }


 Now you can select a direction on the each container?

 Naturally, this would avoid performing a copy of the content, and the
 basic approach is quite easy to handle via a struct containing an
 opApply(). It would open the door to alternate iteration approaches
 also, such as skipping entries, merging, or whatever.

 Tango does something vaguely like this for the text-iterators in
 tango.text.Util




 What if collection3 is a 40 MB array?

 The nice thing about foreach_reverse is that it doesn't require any
 transformations on the data.  



 I didn't suggest transformation at all :) Merely a mean of satisfying
 opApply that happens to go backwards instead (or some other pattern).



I realise this, but my point was that 'reverse' on an array *actually*
reverses the array.  If we have it return a struct that implements
opApply, then people are going to wonder why 'arr.reverse' doesn't
reverse the array.

At least with operator overloads, we can keep them separate.

That said, maybe something along the lines of .iterReverse or somesuch
would work... but then, it would be nice to not have to stuff around
with all these structs :P  *dreams of having Python-style generators*

The other thing to think about is that we shouldn't have to use a member
function of a structure when the compiler should *know* how to go
backwards over a silly little array.

But then, maybe that's just me :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 22 2007
prev sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Daniel Keep wrote:

 In any case, I like the idea of having foreach(scheme), where "scheme"
 could be "forward", "reverse", "depthfirst", "topological", whatever.
 And if D2.0 gets generators as well... well, I can't think of any other
 procedural language that could even come close to touching us :)
 
 	-- Daniel
 
 P.S. One last thought:
 
 class Heap
 {
     int opApply(...) { ... dg(v); ... }
     int opApplyReverse(...) { ... }
     int opApply_depthfirst(...) { ... }
     int opApply_sorted(...) { ... }
 
     // Wouldn't it be cool if the above could be written as...
 
     foreach(...) { foreach( v ; this.backing ) yield v; }
     foreach(reverse)(...) { ... }
     foreach(depthfirst)(...) { ... }
     foreach(sorted)(...) { ... }
 }
 



That /would/ be cool. I think a syntax like "foreach (delegate) (index, data;
collection)" instead of the current "foreach (index, data;
&delegate(collection))" would be really nice.
Mar 21 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
kris wrote:

 janderson wrote:

 Andrei Alexandrescu (See Website For Email) wrote:


 Derek Parnell wrote:


 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball 
 keyword who is disparaged by the other kids because of his obesity 
 and the big staple in his belly button.




 LOL ... Now that *is* funny.




 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei




 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) 
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator mechanism. 
 You could define what order items are visited.  I mean, reverse would 
 not be a keyword at all and would exist in some library.  Although I'm 
 not sure how it would be implemented, and it may defeat the purpose of 
 foreach_reverse being optimal.

 Just a thought.



 shouldn't this perhaps be something like:
 
 foreach (item; collection) (item2; x->GetColection(b))(item3; 
 collection3.reverse)
 {
 
 }
 
 
 Now you can select a direction on the each container?
 
 Naturally, this would avoid performing a copy of the content, and the 
 basic approach is quite easy to handle via a struct containing an 
 opApply(). It would open the door to alternate iteration approaches 
 also, such as skipping entries, merging, or whatever.
 
 Tango does something vaguely like this for the text-iterators in 
 tango.text.Util



I agree.

Walter posted about this in another thread saying foreach_reverse was 
that way because of some performance nitch.  I still think that 
foreach_reverse is not the right way to do a reverse.  I think having it 
as a member or free function is the best.  The compiler should be able 
to detect .reverses on primitive arrays and optimize them.

Besides, how does the compiler currently optimize something written as 
an opApply?
Mar 21 2007
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
janderson skrev:


 Walter posted about this in another thread saying foreach_reverse was 
 that way because of some performance nitch.



That's right. The DMD compiler isn't able to inline functions containing 
loops. Also, it is unable to inline calls to compile time known const 
(invariant?) delegates. Instead of fixing that, a new special case 
keyword is introduced.


 I still think that 
 foreach_reverse is not the right way to do a reverse.  I think having it 
 as a member or free function is the best.



I Agree.


 The compiler should be able 
 to detect .reverses on primitive arrays and optimize them.



Or even better, fix the compiler issues with inlining. Here is a trivial 
reverse array viewer I've been using since long before foreach_reverse 
was introduced. It doesn't perform extremely well for the above 
mentioned reasons, but I've always been thinking that one day a decent 
compiler would generate close to optimal code out of this.

struct ReverseIterator(T:T[]) {
         T[] array;

         int opApply(int delegate(inout T) dg) {
                 for (int i = array.length-1; i >= 0; i--) {
                         if (auto status = dg(array[i]))
                                 return status;
                 }
                 return 0;
         }
}

ReverseIterator!(Array) reverseView(Array)(Array array) {
         ReverseIterator!(Array) iter = {array};
         return iter;
}

import std.stdio;
void main() {
         foreach(x; reverseView("abcdx"))
                 writefln("%s",x);
}


 Besides, how does the compiler currently optimize something written as 
 an opApply?



It doesn't.

The introduction of foreach_reverse resolved the above mentioned 
performance issue with iterating backwards over an array, but didn't 
resolve either:

* Iterating backwards over any other container/view that implements 
random access semantics.

* Efficiently implementing other view constructs, such as:

foreach(person; employees.select((Person p){ return p.age > 65; }))

foreach(t; str.tokenize(" "))

foreach(d; data.selectIndices(indexArray))

etc...

foreach_reverse doesn't generalize anything. A container that implements 
random access semantics will not automatically be foreach_reversible. 
Everyone wanting to make a standard container will have to implement a 
silly opApplyReverse method that serves no real use. The performance 
will not be any better than using a generic reverse viewer and this was 
the only argument for adding foreach_reverse.

IMHO, foreach_reverse is an aberration in so many ways and the sooner it 
is gone the better.

/Oskar
Mar 22 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Oskar Linde wrote:

 janderson skrev:
 

 Walter posted about this in another thread saying foreach_reverse was 
 that way because of some performance nitch.



 That's right. The DMD compiler isn't able to inline functions containing 
 loops. Also, it is unable to inline calls to compile time known const 
 (invariant?) delegates. Instead of fixing that, a new special case 
 keyword is introduced.
 

 I still think that foreach_reverse is not the right way to do a 
 reverse.  I think having it as a member or free function is the best.



 I Agree.
 

 The compiler should be able to detect .reverses on primitive arrays 
 and optimize them.



 Or even better, fix the compiler issues with inlining. Here is a trivial 
 reverse array viewer I've been using since long before foreach_reverse 
 was introduced. It doesn't perform extremely well for the above 
 mentioned reasons, but I've always been thinking that one day a decent 
 compiler would generate close to optimal code out of this.
 
 struct ReverseIterator(T:T[]) {
         T[] array;
 
         int opApply(int delegate(inout T) dg) {
                 for (int i = array.length-1; i >= 0; i--) {
                         if (auto status = dg(array[i]))
                                 return status;
                 }
                 return 0;
         }
 }
 
 ReverseIterator!(Array) reverseView(Array)(Array array) {
         ReverseIterator!(Array) iter = {array};
         return iter;
 }
 
 import std.stdio;
 void main() {
         foreach(x; reverseView("abcdx"))
                 writefln("%s",x);
 }
 

 Besides, how does the compiler currently optimize something written as 
 an opApply?



 It doesn't.
 
 The introduction of foreach_reverse resolved the above mentioned 
 performance issue with iterating backwards over an array, but didn't 
 resolve either:
 
 * Iterating backwards over any other container/view that implements 
 random access semantics.
 
 * Efficiently implementing other view constructs, such as:
 
 foreach(person; employees.select((Person p){ return p.age > 65; }))
 
 foreach(t; str.tokenize(" "))
 
 foreach(d; data.selectIndices(indexArray))
 
 etc...
 
 foreach_reverse doesn't generalize anything. A container that implements 
 random access semantics will not automatically be foreach_reversible. 
 Everyone wanting to make a standard container will have to implement a 
 silly opApplyReverse method that serves no real use. The performance 
 will not be any better than using a generic reverse viewer and this was 
 the only argument for adding foreach_reverse.
 
 IMHO, foreach_reverse is an aberration in so many ways and the sooner it 
 is gone the better.
 
 /Oskar



Very well said, I subscribe fully.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:

 janderson wrote:

 Andrei Alexandrescu (See Website For Email) wrote:


 Derek Parnell wrote:


 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball 
 keyword who is disparaged by the other kids because of his obesity 
 and the big staple in his belly button.




 LOL ... Now that *is* funny.




 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei




 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) 
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator mechanism. 
 You could define what order items are visited.  I mean, reverse would 
 not be a keyword at all and would exist in some library.  Although I'm 
 not sure how it would be implemented, and it may defeat the purpose of 
 foreach_reverse being optimal.

 Just a thought.



 shouldn't this perhaps be something like:
 
 foreach (item; collection) (item2; x->GetColection(b))(item3; 
 collection3.reverse)
 {
 
 }
 



Or better still, if we wanted to keep 'reverse' away from the collection:

foreach (item; collection) (item2; x->GetColection(b)) (item3; collection3;
reverse) {
}

I wouldn't be above a 'foreach(i,x ; source ; order)' syntax in general, really.

-- Chris Nicholson-Sauls
Mar 22 2007
parent reply kris <foo bar.com> writes:
Chris Nicholson-Sauls wrote:

 
 
 kris wrote:
 

 janderson wrote:


 Andrei Alexandrescu (See Website For Email) wrote:


 Derek Parnell wrote:


 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball 
 keyword who is disparaged by the other kids because of his obesity 
 and the big staple in his belly button.





 LOL ... Now that *is* funny.





 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely 
 becoming a D signature syntax.


 Andrei





 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) 
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator 
 mechanism. You could define what order items are visited.  I mean, 
 reverse would not be a keyword at all and would exist in some 
 library.  Although I'm not sure how it would be implemented, and it 
 may defeat the purpose of foreach_reverse being optimal.

 Just a thought.




 shouldn't this perhaps be something like:

 foreach (item; collection) (item2; x->GetColection(b))(item3; 
 collection3.reverse)
 {

 }



 Or better still, if we wanted to keep 'reverse' away from the collection:
 
 foreach (item; collection) (item2; x->GetColection(b)) (item3; 
 collection3; reverse) {
 }
 
 I wouldn't be above a 'foreach(i,x ; source ; order)' syntax in general, 
 really.
 
 -- Chris Nicholson-Sauls



Except for one thing, Chris; basing the syntax on 'keywords' limits one 
to what the compiler chooses to support? Basing the opApply() selection 
on a method/property name instead (with optional arguments also) leaves 
the door wide open for any implementation you can imagine?
Mar 21 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:

 Chris Nicholson-Sauls wrote:

 kris wrote:


 janderson wrote:


 Andrei Alexandrescu (See Website For Email) wrote:


 Derek Parnell wrote:


 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball 
 keyword who is disparaged by the other kids because of his 
 obesity and the big staple in his belly button.





 LOL ... Now that *is* funny.





 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely 
 becoming a D signature syntax.


 Andrei





 //Using your other suggestion:
 foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) 
 (item3 ; collection3)
 {

 }

 Its starting to get hard and harder to read IMO.

 Although perhaps the reverse could be come sort of iterator 
 mechanism. You could define what order items are visited.  I mean, 
 reverse would not be a keyword at all and would exist in some 
 library.  Although I'm not sure how it would be implemented, and it 
 may defeat the purpose of foreach_reverse being optimal.

 Just a thought.




 shouldn't this perhaps be something like:

 foreach (item; collection) (item2; x->GetColection(b))(item3; 
 collection3.reverse)
 {

 }



 Or better still, if we wanted to keep 'reverse' away from the collection:

 foreach (item; collection) (item2; x->GetColection(b)) (item3; 
 collection3; reverse) {
 }

 I wouldn't be above a 'foreach(i,x ; source ; order)' syntax in 
 general, really.

 -- Chris Nicholson-Sauls



 Except for one thing, Chris; basing the syntax on 'keywords' limits one 
 to what the compiler chooses to support? Basing the opApply() selection 
 on a method/property name instead (with optional arguments also) leaves 
 the door wide open for any implementation you can imagine?



I was actually thinking the third "parameter" should be one of: function,
function 
pointer, delegate, variable containing referance to a delegate; rather than
some 
language-defined set of order keywords.

int reverse   (T,U) (int delegate(U,T) dg) {}
int scattered (T,U) (int delegate(U,T) dg) {}

foreach (i,x ; some_array ; reverse  ) {}
foreach (i,x ; some_array ; scattered) {}

It would seperate ordering algorithms from the collections themselves, and also
not 
prevent that approach so long as the current allowance for delegates and usage
of opApply 
were retained (as, presumably, they would be).  Just a crazy idea.

-- Chris Nicholson-Sauls
Mar 22 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Chris Nicholson-Sauls wrote:

 kris wrote:

 Chris Nicholson-Sauls wrote:

 kris wrote:


 janderson wrote:
 [snip]



 Or better still, if we wanted to keep 'reverse' away from the
 collection:

 foreach (item; collection) (item2; x->GetColection(b)) (item3;
 collection3; reverse) {
 }

 I wouldn't be above a 'foreach(i,x ; source ; order)' syntax in
 general, really.

 -- Chris Nicholson-Sauls



 Except for one thing, Chris; basing the syntax on 'keywords' limits
 one to what the compiler chooses to support? Basing the opApply()
 selection on a method/property name instead (with optional arguments
 also) leaves the door wide open for any implementation you can imagine?



 I was actually thinking the third "parameter" should be one of:
 function, function pointer, delegate, variable containing referance to a
 delegate; rather than some language-defined set of order keywords.
 
 int reverse   (T,U) (int delegate(U,T) dg) {}
 int scattered (T,U) (int delegate(U,T) dg) {}
 
 foreach (i,x ; some_array ; reverse  ) {}
 foreach (i,x ; some_array ; scattered) {}
 
 It would seperate ordering algorithms from the collections themselves,
 and also not prevent that approach so long as the current allowance for
 delegates and usage of opApply were retained (as, presumably, they would
 be).  Just a crazy idea.
 
 -- Chris Nicholson-Sauls



I think the third parameter should also be usable as:


 class Foo
 {
     int opApply_scattered(...) { ... }
 }

 foreach (i,x ; new Foo ; scattered) {}



Reason being that if you implement "scattered" as a template, and my
class doesn't implement whatever interface you're using, I'm stuffed.

But I do rather like the thought of the third parameter being a function
of some description.  Cleanly separates the thing you're iterating over,
and *how* you're iterating over it.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 22 2007
prev sibling parent reply kris <foo bar.com> writes:
Chris Nicholson-Sauls wrote:
[snip]

 I was actually thinking the third "parameter" should be one of: 
 function, function pointer, delegate, variable containing referance to a 
 delegate; rather than some language-defined set of order keywords.



ah; sorry ... I totally missed that :)
Mar 22 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:

 Chris Nicholson-Sauls wrote:
 [snip]

 I was actually thinking the third "parameter" should be one of: 
 function, function pointer, delegate, variable containing referance to 
 a delegate; rather than some language-defined set of order keywords.



 ah; sorry ... I totally missed that :)



I totally failed to mention it, I think.  ;)

-- Chris Nicholson-Sauls
Mar 22 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if you 
 asked 100 people which of 'const' and 'CONST' was the most constant 
 you'd probably get 100 votes for 'CONST'.  And he could become good 
 friends with foreach_reverse, the other odd-ball keyword who is 
 disparaged by the other kids because of his obesity and the big 
 staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 
 Andrei



I guess one extension to this syntax could be constant iterations (the 
values in the array don't change:

foreach (const) (item ; collection)
{

}

I still think

const foreach (item; collection)
{

}

is better if we did have a feature like this.
Mar 21 2007
parent janderson <askme me.com> writes:
janderson wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Derek Parnell wrote:

 On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:


 Here's a random thought:
 What about const vs CONST?
 The upcase version obviously being the more const of the two.
 The original proposal played with punctuation, and we've talked 
 plenty about spelling, but we haven't talked about playing with 
 case.  It would be an odd-ball among keywords, admittedly, but if 
 you asked 100 people which of 'const' and 'CONST' was the most 
 constant you'd probably get 100 votes for 'CONST'.  And he could 
 become good friends with foreach_reverse, the other odd-ball keyword 
 who is disparaged by the other kids because of his obesity and the 
 big staple in his belly button.



 LOL ... Now that *is* funny.



 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 I guess one extension to this syntax could be constant iterations (the 
 values in the array don't change:
 
 foreach (const) (item ; collection)
 {
 
 }
 
 I still think
 
 const foreach (item; collection)
 {
 
 }
 
 is better if we did have a feature like this.



Now that I think about it:

foreach (const item; collection)
{

}

is probably best.
Mar 22 2007
prev sibling parent reply Reiner Pope <reiner none.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Yah :o). Speaking of foreach_reverse, probably it would be wise to lobby 
 Walter to deprecate it in favor of foreach(reverse) (item ; collection) 
 { ... }. The keyword(extra) syntax is definitely becoming a D signature 
 syntax.
 
 
 Andrei



allow trailing delegates to support arbitrary iterating (see 
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=4940)

It was met with a very positive reaction back then, but nothing ever 
really came of it.

Basically, it allows iteration styles of any name, as people are 
suggesting again now, but instead of the foreach(iteration_style)(item; 
collection) syntax suggested here, you could just write:

     collection.iteration_style (item) { code; }

So you would get things like:

     collection.random_each (i) { writefln(i); }

Feature-wise, this doesn't add much to what people suggest here, but it 
makes sense when you want to go beyond foreach-style iterators. Also, 
some things are just better expressed without the 'foreach' there to get 
in the way:

     5.times { writefln("Hello World!"); }

Let's face it: you can do more stuff with delegates than can be 
described by saying 'for each element of some set.'

Cheers,

Reiner
Mar 22 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 allow trailing delegates to support arbitrary iterating (see 
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.a
nounce&artnum=4940) 
 
 
 It was met with a very positive reaction back then, but nothing ever 
 really came of it.
 
 Basically, it allows iteration styles of any name, as people are 
 suggesting again now, but instead of the foreach(iteration_style)(item; 
 collection) syntax suggested here, you could just write:
 
     collection.iteration_style (item) { code; }
 
 So you would get things like:
 
     collection.random_each (i) { writefln(i); }
 
 Feature-wise, this doesn't add much to what people suggest here, but it 
 makes sense when you want to go beyond foreach-style iterators. Also, 
 some things are just better expressed without the 'foreach' there to get 
 in the way:
 
     5.times { writefln("Hello World!"); }
 
 Let's face it: you can do more stuff with delegates than can be 
 described by saying 'for each element of some set.'



Walter is seriously considering this for addition; thanks for bringing 
it up again.


Andrei
Mar 22 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Reiner Pope wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Yah :o). Speaking of foreach_reverse, probably it would be wise to 
 lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
 collection) { ... }. The keyword(extra) syntax is definitely becoming 
 a D signature syntax.


 Andrei



 0.170: allow trailing delegates to support arbitrary iterating (see 
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.a
nounce&artnum=4940) 


 It was met with a very positive reaction back then, but nothing ever 
 really came of it.

 Basically, it allows iteration styles of any name, as people are 
 suggesting again now, but instead of the 
 foreach(iteration_style)(item; collection) syntax suggested here, you 
 could just write:

     collection.iteration_style (item) { code; }

 So you would get things like:

     collection.random_each (i) { writefln(i); }

 Feature-wise, this doesn't add much to what people suggest here, but 
 it makes sense when you want to go beyond foreach-style iterators. 
 Also, some things are just better expressed without the 'foreach' 
 there to get in the way:

     5.times { writefln("Hello World!"); }

 Let's face it: you can do more stuff with delegates than can be 
 described by saying 'for each element of some set.'



 Walter is seriously considering this for addition; thanks for bringing 
 it up again.
 
 
 Andrei



One of my beloved Ruby features a candidate for D??  Okay... you guys must be
putting us 
on.  This is just too much.  ;)

Any chance of an ETA for the next release?

-- Chris Nicholson-Sauls
Mar 22 2007
parent reply Dan <murpsoft hotmail.com> writes:
A "delegate" is it?  Don't you mean "function"?  "delegate"s are for classes,
and I sure hope that 3 won't become a class.

If we're using functions as iterators, we'd have to use asm { naked; } to
prevent ourselves from suffering call stack overhead.  Also, what of loop
optimization?  I suppose it becomes implementation specific now doesn't it?

Well if that's the case, we're pretty close already.

There's syntactic sugar for this:

// inline this
char dansLoopy(char[] s, function x){
  
}
myString.dansLoopy(x);

Of course, you'd want to make sure x was inlined and didn't rattle the stack
(iteratively calling a method 1000 times doing extra push/ pop/ push/ pop/
push/ pop)

Meh.
Mar 22 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Mar 2007 15:20:20 -0400, Dan wrote:


 A "delegate" is it?  Don't you mean "function"?  "delegate"s are
 for classes, and I sure hope that 3 won't become a class.



Actually, aren't delegates for anything with a context and not just
classes?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
23/03/2007 1:22:46 PM
Mar 22 2007