bob at redivi.com
Mon Jun 26 14:43:14 PDT 2006
On Jun 26, 2006, at 2:09 PM, Chris Double wrote:
> On 6/27/06, Brendan Eich <brendan at mozilla.org> wrote:
>> Yes, and that is a concern for us, for Rhino's Continuation object
>> implementation (which cannot cross Java native frames), as for
> There are ways around the inability to yield across C stack frames. A
> Jit was recently announced for Lua that supports yielding from C
> functions and returning to them (provided by the Coco patch):
> yield from functions called from the generator is a pain. But that
> model has been in use for a while in the Python world - do they find
> it a practical limitation?
In the Python world you don't "yield across" anything. Functions that
use yield, when called, return a generator object with a next method.
The next method executes the function until a yield or an exception
 and returns the value yielded. Generators help out considerably
for a lot of use cases, but they're definitely not equivalent to
coroutines in any practical sense. This isn't generally considered to
be a pain, because generators aren't purporting to be coroutines and
most users aren't going to be familiar with something like call/cc
PEP 342 turns yield into an expression that has a value or may raise
an arbitrary exception depending on what the caller does (by adding
the send and throw methods). It allows for coroutine-like behavior,
but the user has to implement it with a trampoline and write code in
a sort of communicating sequential processes style. It does not allow
for "magical" behavior like implicit cooperative threading on I/O.
From the Python design perspective, this is generally considered to
be a good thing according to EIBTI ("explicit is better than
 bare return and falling off the end of the function are
equivalent to "raise StopIteration".
More information about the Es4-discuss