March 22, 2007 Re: Differentiate const flavors using CASE? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | 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
|
March 22, 2007 Re: Differentiate const flavors using CASE? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
March 23, 2007 Re: Differentiate const flavors using CASE? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan | 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 |
March 23, 2007 Re: Differentiate const flavors using CASE? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Oskar Linde | 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 |
Copyright © 1999-2021 by the D Language Foundation