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.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.'
> 
> 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

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.

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

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