foreach vs. iterators

Bill Baxter wbaxter at gmail.com
Fri Nov 3 18:47:07 PST 2006


Benji Smith wrote:
> Bill Baxter wrote:
> 
>> There's no way I can see to stop that juggernaut before it's done, 
>> short of having it return, and if it returns then it'll lose its 
>> state. Conceptually what you need is a 'yield' that keeps the current 
>> stack frame alive, but returns to the caller.
> 
> 
> But then your object can only have one iterator at a time, and what if 
> you want to have multiple simultaneous iterators for any given object? 
> The 'yield' keyword can only keep track of state for a single iterator, 
> so this kind of code would fail:
> 
>   foreach (Item outerItem; collection) {
>     foreach (Item innerItem; collection) {
>       doSomething(outerItem, innerItem);
>     }
>   }

No it wouldn't.  Not if you had support for real coroutines.  That's the 
whole point of coroutines.  You can have multiple stack frames active at 
the same time.   Each stack frame for the opApply's in the above case 
would have its own local iterator state.

Now whether or not coroutines are realistically implementable in a 
systems programming language like D is beyond me.  Stackless Python 
folks did it, but perhaps they're taking advantage of the fact that 
users of interpreted code are a bit more forgiving about runtime 
overhead, and the fact that the interpreter has its own notion of the 
stack that doesn't depend on low-level processor details like EAX 
registers etc.  But technically I don't see any roadblocks.  I mean I 
read somewhere that coroutines are an old assembly programming trick, so 
the hardware is certainly capable of supporting the paradigm at the low 
level.  It's basically just a jmp plus a manipulation of the stack 
pointer when it comes right down to it.

--bb



More information about the Digitalmars-d-announce mailing list