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.
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?
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.
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?
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.
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?
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
I'm surprised no-one has mentioned Tom S's proposal back from DMD 0.170: 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
I'm surprised no-one has mentioned Tom S's proposal back from DMD 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
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
I'm surprised no-one has mentioned Tom S's proposal back from DMD 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