[VOTE] Generator Delegation

Hi Daniel,

In the formal definition, you have:

$throw $e;

... which I assume is a typo?

Damien

Woops! Yes, this is a typo. Thanks for the heads-up; fixing now ...

2015-03-15 21:13 GMT+01:00 Damien Tournoud damz@damz.org:

Hi Daniel,

Would you mind clarifying the relationship between the "Generator
Delegation" RFC and the "Generator Return Expressions" RFC?

While I really appreciate the "Generator Delegation" RFC, the "Generator
Return Expressions" looks both unnecessary and kind of a hack to me. 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...). Essentially, "returning a value" is an abstraction of the
cooperative framework (usually an event loop), not of the generator itself.

I already wanted to ask why you voted no on return expressions. The reason
for having delegation dependent on return expression is that coroutines can
have a result that should be available just like any other function.

$result = yield from coroutine();

Without return expressions, there would be no way to access the result of a
coroutine.

The relevant section in the RFC should be the following:
https://wiki.php.net/rfc/generator-return-expressions#use-casecoroutine_return_values

I hope that clarifies it, if not, please ask again.

Regards, Niklas

Damien

Hi folks!

As the discussion period has reached its conclusion I'd like to announce
a
two week voting period on the Generator Delegation RFC here:

https://wiki.php.net/rfc/generator-delegation

Voting ends Sunday, March 29.

I know everyone is busy and your time is valuable; thanks for spending a
few minutes to review the proposal. If you have any questions please
don't
hesitate to ask.

-Daniel

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.