Everything

php

[VOTE] Generator Delegation

php.internals

Daniel Lowrey

11 years ago

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

Damien Tournoud

11 years ago

Hi Daniel,

In the formal definition, you have:

$throw $e;

... which I assume is a typo?

Damien

On Sun, Mar 15, 2015 at 8:18 PM, Daniel Lowrey <rdlowrey@php.net> wrote:

Daniel Lowrey

11 years ago

On Sun, Mar 15, 2015 at 3:56 PM, Damien Tournoud <damz@damz.org> wrote:

>
> 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 ...

Damien Tournoud

11 years ago

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.

Damien


On Sun, Mar 15, 2015 at 8:18 PM, Daniel Lowrey <rdlowrey@php.net> wrote:

Niklas Keller

11 years ago

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

Daniel Lowrey

11 years ago

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.

Damien Tournoud

11 years ago

On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey <rdlowrey@php.net> wrote:

> 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.
>

Hi Daniel,

I actually disagree here. Using generators as coroutine is a hack, and is
vastly inferior to having actual coroutine support in the language, but
obviously we do what we can with the language we have.

(Yes, I am in the camp that *really* dislike explicit yielding.)

I do understand where this is coming from, so changing my vote to yes on
the other RFC.

Damien

Daniel Lowrey

11 years ago

On Sun, Mar 15, 2015 at 4:39 PM, Damien Tournoud <damz@damz.org> wrote:

>
> On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey <rdlowrey@php.net> wrote:
>>
>> 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.

>
>
> Hi Daniel,
>
> I actually disagree here. Using generators as coroutine is a hack, and is

vastly inferior to having actual coroutine support in the language, but
obviously we do what we can with the language we have.

>
> (Yes, I am in the camp that *really* dislike explicit yielding.)
>
> I do understand where this is coming from, so changing my vote to yes on

the other RFC.

>
> Damien
>

I can appreciate your viewpoint :)

We do what we can with the tools we have at our disposal. If you don't want
to see it happen then I can live with that. It is, my job, as the RFC
author to persuade people. Thanks for your honest input!

Pascal MARTIN

11 years ago

Le 15/03/2015 20:18, Daniel Lowrey a écrit :

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

Hi,

Only a few people at AFUP discussed this RFC (I suppose it's the kind of
feature not everyone will use), but those of us who did are +1.

Thanks!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/