I meant that "yield next" would only transform the method (or block) that lexically encloses it. Like in Python. If we wanted to propagate the state transformation across methods we could also introduce "yield foreach" construct [1].

[1] http://citeseer.ist.psu.edu/cache/papers/cs2/355/http:zSzzSzwww.cs.kuleuven.ac.bezSz~frankzSzPAPERSzSzFTfJP2005.pdf/iterators-revisited-proof-rules.pdf

Tomas

-----Original Message-----
From: Charles Oliver Nutter [mailto:headius / headius.com] 
Sent: Friday, September 25, 2009 6:51 PM
To: ruby-core / ruby-lang.org
Subject: [ruby-core:25781] Re: A challenge: Enumerator#next in JRuby

On Fri, Sep 25, 2009 at 8:11 PM, Tomas Matousek <Tomas.Matousek / microsoft.com> wrote:
> Wouldn't Python style generators be enough for most use cases? It would require a "yield next" keyword ("yield" is already taken) that would instruct the compiler to transform the calling function into a state machine. On the other hand, it would make users happy that they don't need to explicitly maintain their state and also implementers happy that they don't need to use fibers/threads.

"yield next" isn't enough because the call stack underneath each could be arbitrarily complex:

def each(&b)
  some_other_eacher(&b)
end

def some_other_eacher
  5.times {|i| yield next i}
end

Or calling through methods that don't normally do iteration at all, like a generator that does a normal enumeration over a regular collection. The effect of generalized coroutines, as in this case, is that without native coroutine support you'd have to transform almost
*everything* into a state machine. And this also won't work at all for calls across native code or libraries that have not been decorated as state machines.

- Charlie