Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84904
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
In-Reply-To: <CALWK-fifzcpUYv0dMhpHa1HJueFxWeALwHC3Y-OkzWfEjTCK0A@mail.gmail.com>
References: <CAH8Mpnkj72HqycPvas0mqCV1sipjjuS2kWmYuFBYc5LzaKQnvw@mail.gmail.com>
	<CALWK-fifzcpUYv0dMhpHa1HJueFxWeALwHC3Y-OkzWfEjTCK0A@mail.gmail.com>
Date: Sun, 15 Mar 2015 16:35:46 -0400
Message-ID: <CAH8MpnnNCUTWc+UzB19sBOkp+gpc=kVP3imSt40JCh9R-NzdiQ@mail.gmail.com>
To: Damien Tournoud <damz@damz.org>
Cc: Daniel Lowrey <rdlowrey@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec51b1be9a04e9d051159ad1c
Subject: Re: [PHP-DEV] [VOTE] Generator Delegation
From: rdlowrey@php.net (Daniel Lowrey)

--bcaec51b1be9a04e9d051159ad1c
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 15, 2015 at 4:13 PM, Damien Tournoud <damz@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.

--bcaec51b1be9a04e9d051159ad1c--