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