On Sun, Mar 15, 2015 at 4:13 PM, Damien Tournoud <d...@damz.org> wrote:
>
> Hi Daniel,
>
> Would you mind clarifying the relationship between the "Generator
Delegation" RFC and the "Generator Return Expressions" RFC?
>
Sure, thanks for the question. As mentioned in the RFC:
"In short: generator delegation allows programmers to reason about the
behaviour of the concurrent code simply by thinking of foo() as an ordinary
function which can be suspended using a yield statement."
Without return expressions in subgenerators you cannot do
$baz = yield from foo($bar);
because the return value $baz has to come from somewhere. The ability to
write the above code is the singular goal of both RFCs; it allows factoring
suspendable functionality into multiple generator functions. Now you could
hack this kind of support together yourself in userland but there's no
reason to do so as return expressions have applicable semantics, known
characteristics and low cognitive overhead as described here:
https://wiki.php.net/rfc/generator-return-expressions#use-casecoroutine_return_values
> In evented system based on coroutine/generators (for example
> Python greenlet/gevent) the ability to "return a value" is handled
> higher up than the generator/coroutine itself, which has other
> advantages (like the ability to yield until the value is available,
> instead of simply throwing, etc...).
This is actually a *vastly* inferior solution to language-level support for
generator returns. greenlet/gevent does it this way because these libraries
were created before Python supported generator delegation (and continue
supporting Python 2.5). When you have generator returns you don't need any
of that additional cruft. Instead, a language supporting generator returns
can simply yield promises (or whatever concurrency primitive you prefer).
Period.
Handling results "higher up than the generator/coroutine" is the hack.
Generator returns are the fix for that hack.
