Nikita Popov | 5 Jun 19:35 2012

[PHP-DEV] Generators in PHP

Hi internals!

In the last few days I've created a proof of concept implementation
for generators in PHP. It's not yet complete, but the basic
functionality is there:
https://github.com/nikic/php-src/tree/addGeneratorsSupport

The implementation is outlined in the RFC-stub here:
https://wiki.php.net/rfc/generators

Before going any further I'd like to get some comments about what you
think of adding generator support to PHP.

If you don't know what generators are you should have a look at the
"Introduction" section in the above RFC or in the Python documentation
at http://wiki.python.org/moin/Generators.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Kris Craig | 5 Jun 20:32 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Tue, Jun 5, 2012 at 10:35 AM, Nikita Popov <nikita.ppv <at> googlemail.com>wrote:

> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
>
> If you don't know what generators are you should have a look at the
> "Introduction" section in the above RFC or in the Python documentation
> at http://wiki.python.org/moin/Generators.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Some observations and questions:

   1. In the RFC, the top example claims to make use of the file()
   function, but in fact does not.  Did you mean fopen()?  Or did you mean
(Continue reading)

Nikita Popov | 6 Jun 19:09 2012

Re: [PHP-DEV] Generators in PHP

On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig <kris.craig <at> gmail.com> wrote:
> Some observations and questions:
>
> In the RFC, the top example claims to make use of the file() function, but
> in fact does not.  Did you mean fopen()?  Or did you mean that this to be an
> example of someone writing their own file() function in PHP for some reason
> (the "userland" reference is a bit confusing IMHO given the context).
It's an implementation of the file() function in userland code (as
opposed to the internal file() implementation). file() returns all
lines from a file as an array.

> In what way(s) do you believe this approach would differ from inline
> functions and what advantage(s) do you see in those differences?
I'm not sure what you mean by inline functions. PHP doesn't do
function inlining (and it doesn't seem related to this). Or do you
mean closures? Again, I'm not sure how closures are related to this.

> What release version do you believe should be targetted for this?
The next major version, i.e. PHP 5.5.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Kris Craig | 6 Jun 21:33 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 10:09 AM, Nikita Popov <nikita.ppv <at> googlemail.com>wrote:

> On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig <kris.craig <at> gmail.com> wrote:
> > Some observations and questions:
> >
> > In the RFC, the top example claims to make use of the file() function,
> but
> > in fact does not.  Did you mean fopen()?  Or did you mean that this to
> be an
> > example of someone writing their own file() function in PHP for some
> reason
> > (the "userland" reference is a bit confusing IMHO given the context).
> It's an implementation of the file() function in userland code (as
> opposed to the internal file() implementation). file() returns all
> lines from a file as an array.
>
> > In what way(s) do you believe this approach would differ from inline
> > functions and what advantage(s) do you see in those differences?
> I'm not sure what you mean by inline functions. PHP doesn't do
> function inlining (and it doesn't seem related to this). Or do you
> mean closures? Again, I'm not sure how closures are related to this.
>

Yes sorry, I meant closures.  I have the nasty habit of calling them
"inline functions," forgetting that that term already means something
completely different lol.

I guess the point I was making is that *closures* and generators are very
similar in many ways.  This isn't to say that generators are a bad idea (I
actually think it's an awesome idea), but the question occurred to me as to
(Continue reading)

Laruence | 6 Jun 04:15 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

Hi Nikita:

    the most important part to me is how did you implemented `yield`
keyword,   is there a whole patch file I can look into?

    what will happen if you use a `yield` in a normal function?

    actually,  I tried to implemented coroutine, but since I could not
find a way to make zend_execute interruptable, then I didn't make it.

    so, I am really interesting of this tech-specific :)

thanks

On Wed, Jun 6, 2012 at 1:35 AM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
>
> If you don't know what generators are you should have a look at the
> "Introduction" section in the above RFC or in the Python documentation
(Continue reading)

Laruence | 6 Jun 04:27 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 10:15 AM, Laruence <laruence <at> php.net> wrote:
> Hi Nikita:
>
>    the most important part to me is how did you implemented `yield`
> keyword,   is there a whole patch file I can look into?
Nervermind,  I will check the branch out later

thanks
>
>    what will happen if you use a `yield` in a normal function?
>
>    actually,  I tried to implemented coroutine, but since I could not
> find a way to make zend_execute interruptable, then I didn't make it.
>
>    so, I am really interesting of this tech-specific :)
>
> thanks
>
> On Wed, Jun 6, 2012 at 1:35 AM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
>> Hi internals!
>>
>> In the last few days I've created a proof of concept implementation
>> for generators in PHP. It's not yet complete, but the basic
>> functionality is there:
>> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>>
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>>
>> Before going any further I'd like to get some comments about what you
(Continue reading)

Laruence | 6 Jun 04:42 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 10:27 AM, Laruence <laruence <at> php.net> wrote:
> On Wed, Jun 6, 2012 at 10:15 AM, Laruence <laruence <at> php.net> wrote:
>> Hi Nikita:
>>
>>    the most important part to me is how did you implemented `yield`
>> keyword,   is there a whole patch file I can look into?
> Nervermind,  I will check the branch out later
>
> thanks

After a quick look,  I think the main idea should goes to two parts:

1. implement yield (Zend)
2. implement spl_generators but not generator class (Spl)

then we can implement spl_coroutine later base on this.  what do you think?

thanks
>>
>>    what will happen if you use a `yield` in a normal function?
>>
>>    actually,  I tried to implemented coroutine, but since I could not
>> find a way to make zend_execute interruptable, then I didn't make it.
>>
>>    so, I am really interesting of this tech-specific :)
>>
>> thanks
>>
>> On Wed, Jun 6, 2012 at 1:35 AM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
>>> Hi internals!
(Continue reading)

Rasmus Lerdorf | 6 Jun 10:11 2012

Re: [PHP-DEV] Generators in PHP

On 06/06/2012 04:42 AM, Laruence wrote:
> On Wed, Jun 6, 2012 at 10:27 AM, Laruence <laruence <at> php.net> wrote:
>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence <laruence <at> php.net> wrote:
>>> Hi Nikita:
>>>
>>>    the most important part to me is how did you implemented `yield`
>>> keyword,   is there a whole patch file I can look into?
>> Nervermind,  I will check the branch out later
>>
>> thanks
> 
> After a quick look,  I think the main idea should goes to two parts:
> 
> 1. implement yield (Zend)
> 2. implement spl_generators but not generator class (Spl)

yield is interesting. It is one of the main features Facebook added, so
it might be worthwhile poking someone there for their implementation
details in order to at least be somewhat compatible.

-Rasmus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye | 6 Jun 11:39 2012
Picon

Re: [PHP-DEV] Generators in PHP

hi Rasmus, Sara,

Adding Sara to the loop as she is around and may miss that thread. We
also tried to convince her to contribute that back to core :)

On Wed, Jun 6, 2012 at 10:11 AM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
> On 06/06/2012 04:42 AM, Laruence wrote:
>> On Wed, Jun 6, 2012 at 10:27 AM, Laruence <laruence <at> php.net> wrote:
>>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence <laruence <at> php.net> wrote:
>>>> Hi Nikita:
>>>>
>>>>    the most important part to me is how did you implemented `yield`
>>>> keyword,   is there a whole patch file I can look into?
>>> Nervermind,  I will check the branch out later
>>>
>>> thanks
>>
>> After a quick look,  I think the main idea should goes to two parts:
>>
>> 1. implement yield (Zend)
>> 2. implement spl_generators but not generator class (Spl)
>
> yield is interesting. It is one of the main features Facebook added, so
> it might be worthwhile poking someone there for their implementation
> details in order to at least be somewhat compatible.
>
> -Rasmus
>
>
> --
(Continue reading)

Anatoliy Belsky | 11 Jun 22:13 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

Hi,

it'd be really cool if the implementation would do the "real" context
switch in c, which would be the true basis for spl_coroutine. The current
implementation seems not to do that.

Context switch in c would be comparable with threads. In fact coroutines
would be a comensation for lacking threads functionality in php, as they
are already implemented on most popular platforms. However, it would
require some platform specific libs (fibers on windows, setjmp and longjmp
on unix(like)).

Coroutines in c are per se thread safe, so implementing them once would
not hurt both ts and nts. Additionally, in some cases coroutines can even
have advantages over the "usual" preemptive threads.

Regards

Anatoliy

Am Mi, 6.06.2012, 04:42 schrieb Laruence:
> On Wed, Jun 6, 2012 at 10:27 AM, Laruence <laruence <at> php.net> wrote:
>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence <laruence <at> php.net> wrote:
>>> Hi Nikita:
>>>
>>>    the most important part to me is how did you implemented `yield`
>>> keyword,   is there a whole patch file I can look into?
>> Nervermind,  I will check the branch out later
>>
>> thanks
(Continue reading)

Tom Boutell | 11 Jun 23:12 2012

Re: [PHP-DEV] Generators in PHP

Can you really use setjmp and longjmp in that way safely? I thought it
was only safe to longjmp "back," not "forward" - you can use them to
fake exception support but that's it because you'll smash the stack
otherwise. Something like that...

OK, I'm thinking of this:

"Similarly, C99 does not require that longjmp preserve the current
stack frame. This means that jumping into a function which was exited
via a call to longjmp is undefined.[6] However, most implementations
of longjmp leave the stack frame intact, allowing setjmp and longjmp
to be used to jump back-and-forth between two or more functions—a
feature exploited for multitasking."

It does not sound like something that can be done in portable C.

On Mon, Jun 11, 2012 at 4:13 PM, Anatoliy Belsky <ab <at> php.net> wrote:
> Hi,
>
> it'd be really cool if the implementation would do the "real" context
> switch in c, which would be the true basis for spl_coroutine. The current
> implementation seems not to do that.
>
> Context switch in c would be comparable with threads. In fact coroutines
> would be a comensation for lacking threads functionality in php, as they
> are already implemented on most popular platforms. However, it would
> require some platform specific libs (fibers on windows, setjmp and longjmp
> on unix(like)).
>
> Coroutines in c are per se thread safe, so implementing them once would
(Continue reading)

Anatoliy Belsky | 12 Jun 00:34 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

Hi,

as i've mentioned, that's up to implementation, for more infos please pay
attention to

http://en.wikipedia.org/wiki/Coroutine#Implementations_for_C

Well, the libtask mentioned there isn't thread safe (but could be made).

Especially have earned some attention

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx#fiber_functions

and

https://github.com/stevedekorte/coroutine

which is portable.

Regards

Anatoliy

Am Mo, 11.06.2012, 23:12 schrieb Tom Boutell:
> Can you really use setjmp and longjmp in that way safely? I thought it
> was only safe to longjmp "back," not "forward" - you can use them to
> fake exception support but that's it because you'll smash the stack
> otherwise. Something like that...
>
> OK, I'm thinking of this:
(Continue reading)

Ángel González | 12 Jun 23:07 2012
Picon

Re: [PHP-DEV] Generators in PHP

On 11/06/12 23:12, Tom Boutell wrote:
> Can you really use setjmp and longjmp in that way safely? I thought it
> was only safe to longjmp "back," not "forward" - you can use them to
> fake exception support but that's it because you'll smash the stack
> otherwise. Something like that...
My first reaction was also "How do you return to the mid-running function?"

However, given that the running function is in PHP-land, I think you could
(in non-zts, it's direct in zts), save EG() contents and replace with
new values,
and then continue the execution.
As it's treating "threads" non-preemtively, that should work.
The C code would also view a different thread, but because it is viewing
different globals (some extensions might need changes). Not really
involving
setjmp() / longjmp().

You could make userland context switches (adding arch-specific code) for
the C code by switching the stack under your ESP, but it's highly likely to
produce some obscure bugs by missing to keep a register...

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Nikita Popov | 13 Jun 00:06 2012

Re: [PHP-DEV] Generators in PHP

On Tue, Jun 12, 2012 at 11:07 PM, Ángel González <keisial <at> gmail.com> wrote:
> On 11/06/12 23:12, Tom Boutell wrote:
>> Can you really use setjmp and longjmp in that way safely? I thought it
>> was only safe to longjmp "back," not "forward" - you can use them to
>> fake exception support but that's it because you'll smash the stack
>> otherwise. Something like that...
> My first reaction was also "How do you return to the mid-running function?"
>
> However, given that the running function is in PHP-land, I think you could
> (in non-zts, it's direct in zts), save EG() contents and replace with
> new values, and then continue the execution.
That's how it is currently implemented. The generator backs up the
current execution context (execute_data, CVs, Ts), pushed stack
arguments and several executor globals. When the generator is resumed
everything is restored and it continues to run as if nothing happened
:)

Doing context switching using setjmp family functions seems to me like
a really scary thing to do. I don't think that one can do that in a
sane way.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Anatoliy Belsky | 14 Jun 12:16 2012
Picon
Picon

Re: [PHP-DEV] Generators in PHP

Am Mi, 13.06.2012, 00:06 schrieb Nikita Popov:

> That's how it is currently implemented. The generator backs up the
> current execution context (execute_data, CVs, Ts), pushed stack
> arguments and several executor globals. When the generator is resumed
> everything is restored and it continues to run as if nothing happened
> :)
>
> Doing context switching using setjmp family functions seems to me like
> a really scary thing to do. I don't think that one can do that in a
> sane way.

I see what you mean but would disagree :) . Working with the php context
only brings only a structural advantage. IMHO practically it's comparable
with a pure php implementation. Where it might be ok for generators as the
lexer must be touched anyway, I was talking about the base for
spl_coroutine mentioned by Laurence.

Also, some sane implementation do exist. Not only oss (see the links in my
previous mail), but even in the premium products, just to be said. Of
course it's complex, but doable, may be not right at the first step.

Anatoliy

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Nikita Popov | 6 Jun 21:23 2012

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 4:15 AM, Laruence <laruence <at> php.net> wrote:
> Hi Nikita:
>
>    the most important part to me is how did you implemented `yield`
> keyword,   is there a whole patch file I can look into?
>
>    what will happen if you use a `yield` in a normal function?
>
>    actually,  I tried to implemented coroutine, but since I could not
> find a way to make zend_execute interruptable, then I didn't make it.
Yes I also faced that problem. The current execute() function accepts
an op_array and initializes the execution context from that
(execute_data + CVs + Ts).

So I added a new function execute_ex() which takes that execution
context directly. The execute() function now works by initializing the
execute_data using a new zend_create_execute_data_from_op_array()
function and then calls execute_ex() with it.

The most relevant commit for this change is
https://github.com/nikic/php-src/commit/f627be52540738e124da7cb1566d7f60a2b6a48b.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Gustavo Lopes | 6 Jun 10:55 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Tue, 5 Jun 2012 19:35:14 +0200, Nikita Popov wrote:
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
>

I approve.

A few comments on the current RFC:

* The RFC is too vague.
* You're violating the contract of Iterator left and right. current() 
and key() should return false when !valid(). next() is underspecified. 
valid() refers to a section that doesn't exist. And if you cannot 
implement rewind(), doing nothing is not an option. In fact, if you 
can't implement Iterator in full, you should implement Traversable 
instead. RewindableGenerator could perhaps implement Iterator though -- 
but I find the nature of RewindableGenerator  very strange. Whether an 
iterator is rewindable or not seems to be related to the nature of the 
generator (e.g., is it reading packets from the network). It's not 
something you can wrap a non-rewindable generator and expect it to work. 
So it's a sort of unsafe operation, like a cast in C.
* Overall, the RFC is very underspecified. We never have a formal 
description of what a generator is and exact semantics of it. There is 
no reference to exceptions. What to do if the generator returns 
function. If the generator can be a function method.
* There are missing sections

I suppose this is a work in progress and that you just want to gauge 
the general interest, and I hope you take these considerations into 
(Continue reading)

Nikita Popov | 7 Jun 01:10 2012

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 10:55 AM, Gustavo Lopes <glopes <at> nebm.ist.utl.pt> wrote:
> On Tue, 5 Jun 2012 19:35:14 +0200, Nikita Popov wrote:
>>
>>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>>
>
> I approve.
>
> A few comments on the current RFC:
>
> * The RFC is too vague.
Yup, it's not yet complete.

> current() and key() should return false when !valid()
Are you sure about that? The Iterator::current() docs don't specify
anything, but the Iterator::key() docs say that it should return NULL
on failure. Checking on the first spl class that came to my mind
SplFixedArray also returns NULL when it is out of elements.

My personal preference would be to throw exceptions if those two
methods are called after the generator was closed (as calling them is
clearly an error, isn't it?), but I see that this would be
inconsistent with the usual iterator behavior.

> next() is underspecified.
Not sure what exactly you mean. next() really doesn't do much more
than resuming the generator. What should I add additionally about it?

(Continue reading)

Anthony Ferrara | 7 Jun 01:37 2012
Picon

Re: [PHP-DEV] Generators in PHP

Nikita,

> I don't know whether that behavior is of any use, so I'll gladly
> change the behavior to throwing an exception if that's more desirable.

You can't throw an exception from rewind, since it's called before
foreach().  So it wouldn't be iterable then.

I think the noop on rewind is valid in this context, as long as it's
documented...

Anthony

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Gustavo Lopes | 7 Jun 10:18 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Thu, 7 Jun 2012 01:10:52 +0200, Nikita Popov wrote:

>> current() and key() should return false when !valid()
>
> Are you sure about that? The Iterator::current() docs don't specify
> anything, but the Iterator::key() docs say that it should return NULL
> on failure. Checking on the first spl class that came to my mind
> SplFixedArray also returns NULL when it is out of elements.

My bad. I was under the impression the semantics were similar to those 
of next(), key(), etc. Instead the docs say under current() that the 
function can return anything, under key) that it returns NULL on failure 
(and issues an E_NOTICE) and for next() that "the return value is 
ignored" -- whatever that means; I'll interpret it as saying anything 
can be returned. I'm not sure how correct this documentation is, though.

>> next() is underspecified.
> Not sure what exactly you mean. next() really doesn't do much more
> than resuming the generator. What should I add additionally about it?

Sorry for not having been clearer. I mean you say "Resumes the 
generator (unless the generator is already closed)", but you don't 
specify what it returns (though apparently Iterator does not re

>
>> valid() refers to a section that doesn't exist.
> Yes, sorry, I hadn't yet written it. I now added it at
> https://wiki.php.net/rfc/generators#closing_a_generator.
>
>> And if you cannot implement rewind(), doing nothing is not an 
(Continue reading)

Gustavo Lopes | 7 Jun 10:46 2012
Picon

Re: [PHP-DEV] Generators in PHP

(Sorry, I pressed something that sent the message prematurely)

On Thu, 7 Jun 2012 01:10:52 +0200, Nikita Popov wrote:

>> current() and key() should return false when !valid()
>
> Are you sure about that? The Iterator::current() docs don't specify
> anything, but the Iterator::key() docs say that it should return NULL
> on failure. Checking on the first spl class that came to my mind
> SplFixedArray also returns NULL when it is out of elements.

My bad. I was under the impression the semantics were similar to those 
of next(), key(), etc. Instead the docs say under current() that the 
function can return anything, under key) that it returns NULL on failure 
(and issues an E_NOTICE) and for next() that "the return value is 
ignored" -- whatever that means; I'll interpret it as saying anything 
can be returned. I'm not sure how correct this documentation is, though.

>> next() is underspecified.
> Not sure what exactly you mean. next() really doesn't do much more
> than resuming the generator. What should I add additionally about it?

Sorry for not having been clearer. I mean you say "Resumes the 
generator (unless the generator is already closed)", but you don't 
specify what it returns (though apparently Iterator does not require you 
to specify anything specific) and you don't say what happens when 
theiterator is already closed.

>> In fact, if you can't implement Iterator in full, you should 
>> implement Traversable instead.
(Continue reading)

Nikita Popov | 8 Jun 13:24 2012

Re: [PHP-DEV] Generators in PHP

On Thu, Jun 7, 2012 at 10:46 AM, Gustavo Lopes <glopes <at> nebm.ist.utl.pt> wrote:
> I mean how do you deal with "return $foo" in the body of the generator? Does
> it work like a final yield? Is the return value ignored?
Currently there will be a fatal error if return statements (with
values) are used in the generator. In the future I'd like to use the
return value as the result of a yield from / yield* expression, as it
is currently done in Python and JavaScript. This is particularly
useful if you are delegating control to another coroutine. This way
you can for example break down a coroutine-based parser into several
functions (instead of having one big ugly function).

> Are you planning on any internal API for functions to implement generators
> (though I really haven't thought how that would work)?
I don't think that this is possible. Generators require that the
execution context is suspended in some way and we have to that control
only over userland code, not internal C code.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Gustavo Lopes | 8 Jun 13:51 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Fri, 8 Jun 2012 13:24:49 +0200, Nikita Popov wrote:
>> Are you planning on any internal API for functions to implement 
>> generators
>> (though I really haven't thought how that would work)?
> I don't think that this is possible. Generators require that the
> execution context is suspended in some way and we have to that 
> control
> only over userland code, not internal C code.
>

Couldn't we simulate this by saving the state in a heap allocated 
structure (whose exact form would depend on the generator 
implementation). Something like:

struct generator_context {
     zval *(*yield_next)(struct generator_context*);
}

struct spec_generator_context {
     struct generator_context parent;
     int foo;
}

PHP_FUNCTION(get_generator)
{
     struct spec_generator_context *ctx = emalloc(*ctx);
     ctx->parent.yield_next = foo_bar();
     return_value = make_internal_generator(ctx);
}

(Continue reading)

Ivan Enderlin @ Hoa | 6 Jun 12:20 2012
Picon

Re: [PHP-DEV] Generators in PHP

On 05/06/12 19:35, Nikita Popov wrote:
> Hi internals!
Hi Nikita,

> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
I have always hoped to see the “yield” keywork introduced in PHP. I even 
suggested that in this mailing-list at least one time but I'm very glad 
to see some patches coming out.

In addition to Gustavo's remarks, I wonder how the GC would collect a 
Generator object that is not use anymore (especially with a referenced 
yield). Does it fit to the current CG strategy or do we need an extra 
strategy? I would notice that the “Yield by reference” section does not 
exist but you have targeted it).
Moreover, I wonder how a “recursive yield” would act (something like 
“public function *f ( … ) { … yield $this->f(…); … }”). It is possible? 
Is it anticipated?

Thanks for you work.

Cheers.

--

-- 
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
(Continue reading)

Lazare Inepologlou | 6 Jun 12:39 2012
Picon

Re: [PHP-DEV] Generators in PHP

Hello Ivan,

Moreover, I wonder how a “recursive yield” would act (something like
> “public function *f ( … ) { … yield $this->f(…); … }”). It is possible? Is
> it anticipated?
>

According to the RFC, your syntax will yield an entire generator and not
its intividual values. Please consider this example:

function * f() { ... }
function * g() {
  yield f();
}
function * h() {
  foreach( f() as $key => $value )
    yield $key => value;
}

The pattern in function h() is quite common, and it is what you ask for. It
would be nice to have some syntactical sugar for it, maybe something like
that:

public function * h() {
  yield foreach f();
}

Good work, I am looking forward to having generators in php.

Lazare INEPOLOGLOU
(Continue reading)

Ángel González | 6 Jun 17:45 2012
Picon

Re: [PHP-DEV] Generators in PHP

On 06/06/12 12:20, Ivan Enderlin  <at>  Hoa wrote:
> On 05/06/12 19:35, Nikita Popov wrote:
>> Hi internals!
> Hi Nikita,
>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
> I have always hoped to see the “yield” keywork introduced in PHP. 
Me too!

It's syntactic sugar around iterators, but a very welcome one.

I'm not sure about the usage as coroutine, though. It looks odd that
->send() which appears into yield.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Nikita Popov | 8 Jun 13:16 2012

Re: [PHP-DEV] Generators in PHP

On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin  <at>  Hoa
<ivan.enderlin <at> hoa-project.net> wrote:
> In addition to Gustavo's remarks, I wonder how the GC would collect a
> Generator object that is not use anymore (especially with a referenced
> yield). Does it fit to the current CG strategy or do we need an extra
> strategy? I would notice that the “Yield by reference” section does not
> exist but you have targeted it).
I added a new section which answers the question at least partially:
https://wiki.php.net/rfc/generators#closing_a_generator
If you don't need the generator object anymore you can either
explicitly ->close() it or wait until all references to it are removed
(typically when leaving the scope of the calling function). When the
generator is closed it releases all used resources, including the
suspended execution context and the currently yielded value. Whether
or not the value is yielded by reference shouldn't make a difference.
So, yes, the current GC strategy works well for generators too :)

> Moreover, I wonder how a “recursive yield” would act (something like “public
> function *f ( … ) { … yield $this->f(…); … }”). It is possible? Is it
> anticipated?
Your particular code would simply yield a generator object (as that's
what $this->f(…) returns).

If instead you wanted to yield all values from that object you could
wrap it in a foreach loop:

function *f() {
    // ...
    foreach ($this->f() as $value) {
        yield $value;
(Continue reading)

Ivan Enderlin @ Hoa | 8 Jun 13:53 2012
Picon

Re: [PHP-DEV] Generators in PHP

Hi Nikita,

On 08/06/12 13:16, Nikita Popov wrote:
> On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin  <at>  Hoa
> <ivan.enderlin <at> hoa-project.net> wrote:
>> In addition to Gustavo's remarks, I wonder how the GC would collect a
>> Generator object that is not use anymore (especially with a referenced
>> yield). Does it fit to the current CG strategy or do we need an extra
>> strategy? I would notice that the “Yield by reference” section does not
>> exist but you have targeted it).
> I added a new section which answers the question at least partially:
> https://wiki.php.net/rfc/generators#closing_a_generator
Good. Thank you.

> If you don't need the generator object anymore you can either
> explicitly ->close() it or wait until all references to it are removed
> (typically when leaving the scope of the calling function). When the
> generator is closed it releases all used resources, including the
> suspended execution context and the currently yielded value. Whether
> or not the value is yielded by reference shouldn't make a difference.
> So, yes, the current GC strategy works well for generators too :)
Ok. A very naive question: would it be interesting to make the 
difference between a “yield” and a “weak referenced yield values” (same 
concept that https://wiki.php.net/rfc/weakreferences which is under 
voting phase as the RFC said).

Thank you for your clarifications.

--

-- 
Ivan Enderlin
(Continue reading)

Jevon Wright | 12 Jun 05:32 2012

Re: [PHP-DEV] Generators in PHP

I don't understand why you need to introduce two new keywords into the
language - * and yield. Could you not solve it like follows?

// Generator implements Iterable
class AllEvenNumbers extends Generator {
  private $i;

  public __construct() { $this->i = 0; }

  function generate() {
    return ($this->i++) * 2;
  }
}

That way I think you can persist state (as part of the class instance)
and implement rewind (per whichever way you do it - either caching the
output, or serialising the class instance) without having to introduce
yet more keywords.

If this is instead a discussion to specifically implement yield,
rather than simplifying the implementation of rewindable Iterators, it
might be more useful to frame the discussion in that way.

Jevon

On Wed, Jun 6, 2012 at 5:35 AM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
(Continue reading)

Nikita Popov | 20 Jul 22:46 2012
Picon

[PHP-DEV] Re: Generators in PHP

On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators

A small progress update on this:

* There now is support for yield by reference
* Generators are now automatically detected by the presence of "yield"
instead of requiring the "*" modifier.

The main open point I still have is whether or not generators should
have a throw() method (á la Python). I couldn't yet find a convincing
use case for it, so I'm considering to just leave it out.

If there is any further feedback on the proposal, I'd love to hear it :)

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Jared Williams | 21 Jul 18:31 2012

RE: [PHP-DEV] Re: Generators in PHP


> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv <at> gmail.com] 
> Sent: 20 July 2012 21:46
> To: Nikita Popov
> Cc: PHP internals
> Subject: [PHP-DEV] Re: Generators in PHP
> 
> On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov 
> <nikita.ppv <at> googlemail.com> wrote:
> > Hi internals!
> >
> > In the last few days I've created a proof of concept
implementation 
> > for generators in PHP. It's not yet complete, but the basic 
> > functionality is there:
> > https://github.com/nikic/php-src/tree/addGeneratorsSupport
> >
> > The implementation is outlined in the RFC-stub here:
> > https://wiki.php.net/rfc/generators
> 
> A small progress update on this:
> 
> * There now is support for yield by reference

Can't yield a reference to an array item directly. 

Eg.

function &map(array &$row)
(Continue reading)

Nikita Popov | 22 Jul 17:52 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

On Sat, Jul 21, 2012 at 6:31 PM, Jared Williams
<jared.williams1 <at> ntlworld.com> wrote:
> Can't yield a reference to an array item directly.
>
> Eg.
>
> function &map(array &$row)
> {
>      yield $row[0];
> }

Thanks, this is fixed now.

> Also seems to be a problem with iterating
>
> foreach(map($row) as &$value)
>
> cannot be done without a fatal error
>
> $i = map($row);
> foreach($i as &$value)
>
> however works.

This was an old foreach restriction that never really made sense and
makes even less sense once generators are in. So I dropped it. Now
everything can be iterated by-reference.

> Seems relatively easy to trigger a infinite loop atm.
>
(Continue reading)

Jared Williams | 25 Jul 23:00 2012

RE: [PHP-DEV] Re: Generators in PHP


> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv <at> gmail.com] 
> Sent: 22 July 2012 16:53
> To: Jared Williams
> Cc: Nikita Popov; PHP internals
> Subject: Re: [PHP-DEV] Re: Generators in PHP
> 
> On Sat, Jul 21, 2012 at 6:31 PM, Jared Williams 
> <jared.williams1 <at> ntlworld.com> wrote:
> > Can't yield a reference to an array item directly.
> >
> > Eg.
> >
> > function &map(array &$row)
> > {
> >      yield $row[0];
> > }
> 
> Thanks, this is fixed now.
> 
> > Also seems to be a problem with iterating
> >
> > foreach(map($row) as &$value)
> >
> > cannot be done without a fatal error
> >
> > $i = map($row);
> > foreach($i as &$value)
> >
(Continue reading)

Nikita Popov | 26 Jul 17:17 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

On Wed, Jul 25, 2012 at 11:00 PM, Jared Williams
<jared.williams1 <at> ntlworld.com> wrote:
> Though here is seemingly another problem, though it could be within
> spl's MultipleIterator()

Thanks, this is fixed now (see
https://github.com/nikic/php-src/commit/268740d9848d435054ce73a8cfe36b2b732cd1f7).
It turned out that you have to implement the Iterator interface before
assigning the get_iterator handler.

Again, thanks for testing the patch and providing useful feedback :)

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Alex Aulbach | 23 Jul 04:25 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/20 Nikita Popov <nikita.ppv <at> gmail.com>:
> On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov <nikita.ppv <at> googlemail.com> wrote:
>> Hi internals!
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>
> A small progress update on this:

> * Generators are now automatically detected by the presence of "yield"
> instead of requiring the "*" modifier.

My first thought was how could someone reading the code see, that it
is a generator?

I mean: The "yield" can be between 50 lines of code. How could someone
see that? That a machine can do this is out of question, but humans
can't see that. Why is this important? Because when I see such code as
in the RFC and overlook the "yield" I would think "WTF", how could the
code work like this?

Why would someone not see  this? Assume that the code was written and
is now quite old. The original developer is gone. A new one sits on
his place and now the customer says "hey, there is a bug anywhere".
The developer begins to search for it, and has no clue, how he can
reproduce it. Maybe he finds a part and he thinks now "Whoa, WTF" and
begins to debug that. After a while he will of course find "Oh, it's a
generator... just forgotten, that PHP can have that and the 'yield' is
so small in the middle of the function, nobody will see that..." But
he has spend some time to find that out.

(Continue reading)

Sara Golemon | 23 Jul 09:49 2012
Picon
Picon

Re: [PHP-DEV] Re: Generators in PHP

>
>
> My first thought was how could someone reading the code see, that it
> is a generator?
>

Somewhat snarky answer: By documenting the code in the first place.

Yeah, I know, we all inherit other people's code and the other person never
writes comments.

I don't think this is as big of a problem in practice, however.  If you're
looking at the function to understand what it does, you're certainly
looking at statements like "return $foo;" already, right?  Why would "yield
$foo;" be any more stealthy?

You posit that future engineer will have to spend hours understanding what
generatorX does because it's 50+ lines long and original engineer isn't
around anymore, but if the function is so complex, then future engineer is
going to be spending hours whether or not it's a generator at all.  Code
like that is just bad code.  The fact that it's a generator isn't the
problem, nor is whether it's been explicitly flagged as such.

Hm... not really satisfied with that.  For me this is a little bit
> unlogical, that just a simple function can return an object.
>
> So, how about implementing as a class? I mean: If it is returning a
> class, why not implement it as class?
>
> Because that misses the entire point of generators as simplified
(Continue reading)

Alex Aulbach | 24 Jul 19:34 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/23 Sara Golemon <pollita <at> php.net>:
> Curious if you could expand on that.  Generators are iterators, so not sure
> what you're asking for.

It's the point which is unlogical for me. Maybe it's a question. If
the generator is an object with the implementation of an iterator, why
do we need to have it as _function_?

-- 
Alex Aulbach

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andrew Faulds | 24 Jul 19:35 2012

Re: [PHP-DEV] Re: Generators in PHP

On 24/07/12 18:34, Alex Aulbach wrote:
> 2012/7/23 Sara Golemon <pollita <at> php.net>:
>> Curious if you could expand on that.  Generators are iterators, so not sure
>> what you're asking for.
> It's the point which is unlogical for me. Maybe it's a question. If
> the generator is an object with the implementation of an iterator, why
> do we need to have it as _function_?
>
Much easier to make an iterator with a function than as a class.

-- 
Andrew Faulds
http://ajf.me/

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Yahav Gindi Bar | 24 Jul 19:42 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

On 24 ביול 2012, at 20:35, Andrew Faulds wrote:

> On 24/07/12 18:34, Alex Aulbach wrote:
>> 2012/7/23 Sara Golemon <pollita <at> php.net>:
>>> Curious if you could expand on that.  Generators are iterators, so not sure
>>> what you're asking for.
>> It's the point which is unlogical for me. Maybe it's a question. If
>> the generator is an object with the implementation of an iterator, why
>> do we need to have it as _function_?
>> 
> Much easier to make an iterator with a function than as a class.
> 
> -- 
> Andrew Faulds
> http://ajf.me/
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

I agree, implementing a class only for iterator may be pain sometimes, and functions is much better -
especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions
in class methods which can be great.
--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Alex Aulbach | 24 Jul 19:56 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
> Much easier to make an iterator with a function than as a class.

2012/7/24 Yahav Gindi Bar <g.b.yahav <at> gmail.com>:
> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better -
especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions
in class methods which can be great.

Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
"function"? It's just the naming, which disturbs me, because a
function is something which is, when called once finished once. I
don't like mathematics, but that is one of the definition of a
function:

http://en.wikipedia.org/wiki/Function_%28mathematics%29
"each input is related to exactly one output"

Couldn't be so complicated to introduce a new name for that, or?

-- 
Alex Aulbach

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andrew Faulds | 24 Jul 20:04 2012

Re: [PHP-DEV] Re: Generators in PHP

On 24/07/12 18:56, Alex Aulbach wrote:
> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>> Much easier to make an iterator with a function than as a class.
> 2012/7/24 Yahav Gindi Bar <g.b.yahav <at> gmail.com>:
>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better -
especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions
in class methods which can be great.
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
>
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
>
> Couldn't be so complicated to introduce a new name for that, or?
>
You'll love LISP, I'm sure, or maybe Python's functional subset.

But PHP functions usually have side-effects, they aren't strict 
mathematical functions.

So complaining about this is rather pointless.

-- 
Andrew Faulds
http://ajf.me/

--

-- 
(Continue reading)

Alex Aulbach | 24 Jul 20:32 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
> But PHP functions usually have side-effects, they aren't strict mathematical
> functions.

Ah, you might mean str_tok()? Are there more, do you have a list?

But we're in PHP-programming-context. You write a function in PHP, you
call it and it will return once called. I see there no exeption.

> So complaining about this is rather pointless.

I don't complain about the past. I just think now, that if it doesn't
behave like a function it shouldn't be called function. A function
which returns as an object and is not completed is not a function.

And if other languages do so, my argument will be the same.

<rising finger with epic mimic, fistulous voice> We need not to make
the same mistake again! :)

-- 
Alex Aulbach

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andrew Faulds | 24 Jul 20:33 2012

Re: [PHP-DEV] Re: Generators in PHP

On 24/07/12 19:32, Alex Aulbach wrote:
> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>> But PHP functions usually have side-effects, they aren't strict mathematical
>> functions.
> Ah, you might mean str_tok()? Are there more, do you have a list?
>
> But we're in PHP-programming-context. You write a function in PHP, you
> call it and it will return once called. I see there no exeption.
>
>> So complaining about this is rather pointless.
> I don't complain about the past. I just think now, that if it doesn't
> behave like a function it shouldn't be called function. A function
> which returns as an object and is not completed is not a function.
>
> And if other languages do so, my argument will be the same.
>
> <rising finger with epic mimic, fistulous voice> We need not to make
> the same mistake again! :)
>
All the array_* functions have side effects. Most class methods, which 
are also functions, have side effects. Most of the functions I write 
have side effects. Much of mysql_* has side effects.

PHP is not LISP.

-- 
Andrew Faulds
http://ajf.me/

--

-- 
(Continue reading)

Alex Aulbach | 24 Jul 20:45 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
> PHP is not LISP.

Hey, I don't want to have LISP. I just want to make complicated things
more clear, and it doesn't matter, if something else is right or wrong
in the past.

It isn't difficult to make a new keyword or something wich disticts it
a little bit more for that.

-- 
Alex Aulbach

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Sherif Ramadan | 25 Jul 05:03 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

> On 24/07/12 19:32, Alex Aulbach wrote:
>>
>> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>>>
>>> But PHP functions usually have side-effects, they aren't strict
>>> mathematical
>>> functions.
>>
>> Ah, you might mean str_tok()? Are there more, do you have a list?
>>
>> But we're in PHP-programming-context. You write a function in PHP, you
>> call it and it will return once called. I see there no exeption.
>>
>>> So complaining about this is rather pointless.
>>
>> I don't complain about the past. I just think now, that if it doesn't
>> behave like a function it shouldn't be called function. A function
>> which returns as an object and is not completed is not a function.
>>
>> And if other languages do so, my argument will be the same.
>>
>> <rising finger with epic mimic, fistulous voice> We need not to make
>> the same mistake again! :)
>>
> All the array_* functions have side effects. Most class methods, which are
> also functions, have side effects. Most of the functions I write have side
> effects. Much of mysql_* has side effects.
>
> PHP is not LISP.
>
(Continue reading)

Alex Aulbach | 25 Jul 09:42 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/25 Sherif Ramadan <theanomaly.is <at> gmail.com>:
> PHP made implementation mistakes in the past that led to awkward
> behavior (like objects passed by value in PHP4), but that's never
> stopped things from moving forward and offering up useful features
> that users want. I think putting the technical details aside the
> engine can aid a developer in distinguishing between spotting
> unintended side effects and preventing disastrous consequences.

I like that kind of agile programming, too.

But if someone like me says "come on, lets make it a little bit more
easy, because returning objects from functions is some kind of
unconventional; many developers will make mistakes here..." - why not?
They will. I can tell by sure.

Since I begun reading this mailing list I have the impression, that
there are only PHP-programmers like us out there. But the fact is,
that the most PHP-programmers didn't even read the manuals completly.
You may say "Their fault" "Are they programmers, if they don't?", but
this is first a little bit of ignorance because second this is one of
the best features, that PHP has - this "nicely flow", everybody can do
it. I always think of Bob Ross, when I explain PHP.

But it's ok, there are no mistakes, there are just happy little accidents. :)

[means: I will not complain any more]

--

-- 
Alex Aulbach

(Continue reading)

Lester Caine | 25 Jul 10:05 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

Alex Aulbach wrote:
>> PHP made implementation mistakes in the past that led to awkward
>> >behavior (like objects passed by value in PHP4), but that's never
>> >stopped things from moving forward and offering up useful features
>> >that users want. I think putting the technical details aside the
>> >engine can aid a developer in distinguishing between spotting
>> >unintended side effects and preventing disastrous consequences.
> I like that kind of agile programming, too.
>
> But if someone like me says "come on, lets make it a little bit more
> easy, because returning objects from functions is some kind of
> unconventional; many developers will make mistakes here..." - why not?
> They will. I can tell by sure.
>
> Since I begun reading this mailing list I have the impression, that
> there are only PHP-programmers like us out there. But the fact is,
> that the most PHP-programmers didn't even read the manuals completly.
> You may say "Their fault" "Are they programmers, if they don't?", but
> this is first a little bit of ignorance because second this is one of
> the best features, that PHP has - this "nicely flow", everybody can do
> it. I always think of Bob Ross, when I explain PHP.

The manual that I read bears no resemblance to the current one, and I still have 
to find a manual that ACTUALLY explains how I should write code that it 'strict' 
compliant. The bulk of the on-line boilerplates are no longer fit for purpose so 
how can we expect newcomers to 'get it right first time'

> But it's ok, there are no mistakes, there are just happy little accidents.:)

That covers most of my best software :)
(Continue reading)

Sherif Ramadan | 25 Jul 10:40 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

>
> I like that kind of agile programming, too.
>
> But if someone like me says "come on, lets make it a little bit more
> easy, because returning objects from functions is some kind of
> unconventional; many developers will make mistakes here..." - why not?
> They will. I can tell by sure.
>

What are suggesting is going to make this easy that isn't already
covered by the RFC? Lets not get caught up in semantics here. The
current RFC outlines what appears to be inline with other established
implementations. The fact that a function can return an object should
be nothing new to PHP. The fact that an object cause some flow of
control through a construct, also shouldn't be new to PHP.

I don't understand what you find non-conventional about functions or
methods that return objects.

function foo() {
  return new bar;
}

$foo = foo();

That's already a common thing in most PHP code I see. PDO::prepare(),
MySQLi::prepare(), DateTime::diff(),  also return objects as a result
of calling those methods. I don't think very many PHP developers will
find this concept difficult to grasp if they can already grasp the
aforementioned methods, for example.
(Continue reading)

Alex Aulbach | 25 Jul 14:43 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/25 Sherif Ramadan <theanomaly.is <at> gmail.com>:
> I don't understand what you find non-conventional about functions or
> methods that return objects.

Again: I don't have any problems with the object returning. :)

I see a problem that the mechanism isn't understood and used wrong.
And I think, that it is too easy to oversee that it is not a "normal"
PHP-function, because the "yield" is normaly in the middle of the code
and "return" at the end.

Both couldn't be changed. But it could help, if you name different
things different. That's just better than nothing. And it's easy. I
suggested that, but the arguments are some kind of ignored.
"No, it's their problem" (of course it is, but it's our job to help
them avoiding this) "No, functions can behave like this, because PHP
is not consistent at all" (of course it is, but this is a completly
new type) "No, we'll do it so, because other languages do it so and we
are used to it" (What an argument is that? Do we want to make a
java-clone?)

> Just between PHP 5.2 and 5.4 we've gained traits, closures,
> namespaces, function array derefrencing, access to member upon
> instantiation, and lots of other lovely additions to the language. I
> don't see languages like Java or Python evolving this quickly -- by
> contrast.

I don't see this as an compelling advantage. If it is done in the
wrong way, the learning curve could become to steep. I have no problem
with it, I use PHP every day, but as explained most PHP-developers
(Continue reading)

Ferenc Kovacs | 25 Jul 16:13 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

>
>
> I use PHP every day, but as explained most PHP-developers
> will have problems and I can say that, because I've more than 20 years
> experience in that. Do you have that?
>

http://en.wikipedia.org/wiki/Appeal_to_authority

> I'm just wondering... for whom is PHP developed, for the PHP-internals
> or for PHP-developers?
>
>
Just wow.
First you say that you are right, because you have more experience in the
topic than the others, then you accuse the "PHP-internals" that they
are favoring their opinion over the rest about the php language development.
I think that argument should either work both ways or none at all.

--

-- 
Ferenc Kovács
 <at> Tyr43l - http://tyrael.hu
Alex Aulbach | 25 Jul 17:37 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/25 Ferenc Kovacs <tyra3l <at> gmail.com>:
>> more than 20 years
>> experience in that. Do you have that?
>
> http://en.wikipedia.org/wiki/Appeal_to_authority

So what? U are using Wikipedia to invalidate me. :) <shrug> Is it so
bad to hear an people with more experience? Do you have problems with
it with authority? :)

So lets make it clear: I say - and I would bet on it - this feature
will cause problems, when implemented like this. Not because of
technical reasons, but because it isn't nicely embedded into PHP.
Normal PHP-programmers will have problems to understand it correctly.
And I'm sure that I'm right, because of my experience. And be warned:
In 90% when I begin to bet, I win. This is also from experience.

> First you say that you are right, because you have more experience in the
> topic than the others, then you accuse the "PHP-internals" that they are
> favoring their opinion over the rest about the php language development.

Name conflict. I meant the PHP-programmers. I call me a PHP-developer,
because I develop programs in PHP. Not a good idea at this list. :)

And yes, I think that there is a more ore less small gap between that,
what the "mass" of anonymous PHP-programmers really needs and that,
what is written in this internals list.
I with you introducing new features like this, but it must be done in
a way that is more self-explaining, has a low learning-curve. Yield
implemented like this dosn't match this criteria.
(Continue reading)

Andrew Faulds | 25 Jul 17:41 2012

Re: [PHP-DEV] Re: Generators in PHP

On 25/07/12 16:37, Alex Aulbach wrote:
> 2012/7/25 Ferenc Kovacs <tyra3l <at> gmail.com>:
>>> more than 20 years
>>> experience in that. Do you have that?
>> http://en.wikipedia.org/wiki/Appeal_to_authority
> So what? U are using Wikipedia to invalidate me. :) <shrug> Is it so
> bad to hear an people with more experience? Do you have problems with
> it with authority? :)
>
> So lets make it clear: I say - and I would bet on it - this feature
> will cause problems, when implemented like this. Not because of
> technical reasons, but because it isn't nicely embedded into PHP.
> Normal PHP-programmers will have problems to understand it correctly.
> And I'm sure that I'm right, because of my experience. And be warned:
> In 90% when I begin to bet, I win. This is also from experience.
>
>> First you say that you are right, because you have more experience in the
>> topic than the others, then you accuse the "PHP-internals" that they are
>> favoring their opinion over the rest about the php language development.
> Name conflict. I meant the PHP-programmers. I call me a PHP-developer,
> because I develop programs in PHP. Not a good idea at this list. :)
>
> And yes, I think that there is a more ore less small gap between that,
> what the "mass" of anonymous PHP-programmers really needs and that,
> what is written in this internals list.
> I with you introducing new features like this, but it must be done in
> a way that is more self-explaining, has a low learning-curve. Yield
> implemented like this dosn't match this criteria.
>
He linked to the Wikipedia "Appeal to authority" article because it's a 
(Continue reading)

Ferenc Kovacs | 25 Jul 17:47 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

>
>
>  He linked to the Wikipedia "Appeal to authority" article because it's a
> common logical fallacy. Experience alone does not make you any more right
> than somebody else, and in the same way, someone without it is not "less
> right".
>
> Also, I have 16 years of experience at life, so obviously I'm an expert at
> it, right?
>
> I don't see how it means anything.
>
>
I'm not arguing that experience doesn't help understanding the issues
related to that experience, what I'm saying is that if someone has more
experience, and he/she is right about his/her statement, then he/she should
have reasons and facts to support his/her opinion and shouldn't use the 'I
have more experience, therefore I'm right' reasoning.

ps: he/she for the honor of
http://www.mail-archive.com/internals <at> lists.php.net/msg58114.html

--

-- 
Ferenc Kovács
 <at> Tyr43l - http://tyrael.hu
Ferenc Kovacs | 25 Jul 17:51 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

On Wed, Jul 25, 2012 at 5:37 PM, Alex Aulbach <alex.aulbach <at> gmail.com>wrote:

> 2012/7/25 Ferenc Kovacs <tyra3l <at> gmail.com>:
> >> more than 20 years
> >> experience in that. Do you have that?
> >
> > http://en.wikipedia.org/wiki/Appeal_to_authority
>
> So what? U are using Wikipedia to invalidate me. :) <shrug> Is it so
> bad to hear an people with more experience? Do you have problems with
> it with authority? :)
>

it seems that you missed the point.
oh well.

--

-- 
Ferenc Kovács
 <at> Tyr43l - http://tyrael.hu
Andrew Faulds | 25 Jul 17:53 2012

Re: [PHP-DEV] Re: Generators in PHP

On 25/07/12 16:51, Ferenc Kovacs wrote:
>
>
> On Wed, Jul 25, 2012 at 5:37 PM, Alex Aulbach <alex.aulbach <at> gmail.com 
> <mailto:alex.aulbach <at> gmail.com>> wrote:
>
>     2012/7/25 Ferenc Kovacs <tyra3l <at> gmail.com <mailto:tyra3l <at> gmail.com>>:
>     >> more than 20 years
>     >> experience in that. Do you have that?
>     >
>     > http://en.wikipedia.org/wiki/Appeal_to_authority
>
>     So what? U are using Wikipedia to invalidate me. :) <shrug> Is it so
>     bad to hear an people with more experience? Do you have problems with
>     it with authority? :)
>
>
> it seems that you missed the point.
> oh well.
>
> -- 
> Ferenc Kovács
>  <at> Tyr43l - http://tyrael.hu
I think this quote from that sums this up nicely: " Although certain 
classes of argument from authority do on occasion constitute strong 
inductive arguments, arguments from authority are commonly used in a 
fallacious manner."

Now, let us not argue about this any more :D

(Continue reading)

Yahav Gindi Bar | 24 Jul 20:06 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

You could introduce new keyword for generator... even call it "generator" but why (its kind of "design"
issue...)? if the syntax that one should use in order to implement the generator is just like a function,
but using yield keyword in order to return the items to store?

As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we
introduce new keyword that can confuse programmers?

I think using function and returning the value using yield is great... although I'm open to any new
nicely-written generator syntax.

On 24 ביול 2012, at 20:56, Alex Aulbach wrote:

> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>> Much easier to make an iterator with a function than as a class.
> 
> 2012/7/24 Yahav Gindi Bar <g.b.yahav <at> gmail.com>:
>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better -
especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions
in class methods which can be great.
> 
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
> 
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
> 
> Couldn't be so complicated to introduce a new name for that, or?
(Continue reading)

Andrew Faulds | 24 Jul 20:08 2012

Re: [PHP-DEV] Re: Generators in PHP

On 24/07/12 19:06, Yahav Gindi Bar wrote:
> You could introduce new keyword for generator... even call it "generator" but why (its kind of "design"
issue...)? if the syntax that one should use in order to implement the generator is just like a function,
but using yield keyword in order to return the items to store?
>
> As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we
introduce new keyword that can confuse programmers?
>
> I think using function and returning the value using yield is great... although I'm open to any new
nicely-written generator syntax.
>
> On 24 ביול 2012, at 20:56, Alex Aulbach wrote:
>
>> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>>> Much easier to make an iterator with a function than as a class.
>> 2012/7/24 Yahav Gindi Bar <g.b.yahav <at> gmail.com>:
>>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better -
especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions
in class methods which can be great.
>> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
>> "function"? It's just the naming, which disturbs me, because a
>> function is something which is, when called once finished once. I
>> don't like mathematics, but that is one of the definition of a
>> function:
>>
>> http://en.wikipedia.org/wiki/Function_%28mathematics%29
>> "each input is related to exactly one output"
>>
>> Couldn't be so complicated to introduce a new name for that, or?
>>
(Continue reading)

Gustavo Lopes | 24 Jul 20:37 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

Em Tue, 24 Jul 2012 19:56:46 +0200, Alex Aulbach <alex.aulbach <at> gmail.com>  
escreveu:

> 2012/7/24 Andrew Faulds <ajf <at> ajf.me>:
>> Much easier to make an iterator with a function than as a class.
>
> 2012/7/24 Yahav Gindi Bar <g.b.yahav <at> gmail.com>:
>> I agree, implementing a class only for iterator may be pain sometimes,  
>> and functions is much better - especially when 5.3 got the anonymous  
>> functions, so we can even use the generators for iterator functions in  
>> class methods which can be great.
>
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
>
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
>

Other have already explained that PHP functions are not strictly  
mathematical functions, but generators nevertheless somewhat fit that  
description. When you have function foo() { ... yield /* ... */; ... } and  
you call foo(), you get the same thing every time: a Generator object. It  
so happens that the implementation of that object is inside the body of  
the function.

Maybe this helps you reason about the feature.
(Continue reading)

Alex Aulbach | 24 Jul 21:13 2012
Picon

Re: [PHP-DEV] Re: Generators in PHP

2012/7/24 Gustavo Lopes <glopes <at> nebm.ist.utl.pt>:
> When you have function foo() { ... yield /* ... */; ... } and
> you call foo(), you get the same thing every time: a Generator object. It so
> happens that the implementation of that object is inside the body of the
> function.

Hmmm. It's not that I didn't understand it. :)

My thoughts are about usage in practice. Ok, my first argument with
the developer, who overtakes an old project was weak.
What about situations, when developers with different knowlegde work together?

Or when you have programming errors, when you write

function blubb()
{
... yields...
...
... return....
}

(you may only see the "return").

And many those situations are thinkable, because this kind of PHP
function works so totally different from current.

> Maybe this helps you reason about the feature.

Please understand me, it's not that I don't like it or that I couldn't
live with it. It's because I have too much experience what could
(Continue reading)

Andrew Faulds | 24 Jul 21:16 2012

Re: [PHP-DEV] Re: Generators in PHP

On 24/07/12 20:13, Alex Aulbach wrote:
> 2012/7/24 Gustavo Lopes <glopes <at> nebm.ist.utl.pt>:
>> When you have function foo() { ... yield /* ... */; ... } and
>> you call foo(), you get the same thing every time: a Generator object. It so
>> happens that the implementation of that object is inside the body of the
>> function.
> Hmmm. It's not that I didn't understand it. :)
>
> My thoughts are about usage in practice. Ok, my first argument with
> the developer, who overtakes an old project was weak.
> What about situations, when developers with different knowlegde work together?
>
> Or when you have programming errors, when you write
>
> function blubb()
> {
> ... yields...
> ...
> ... return....
> }
>
> (you may only see the "return").
>
> And many those situations are thinkable, because this kind of PHP
> function works so totally different from current.
>
>
>> Maybe this helps you reason about the feature.
> Please understand me, it's not that I don't like it or that I couldn't
> live with it. It's because I have too much experience what could
(Continue reading)

Sara Golemon | 25 Jul 04:19 2012

Re: [PHP-DEV] Re: Generators in PHP

>
> Or when you have programming errors, when you write
>
> function blubb()
> {
> ... yields...
> ...
> ... return....
> }
>
> (you may only see the "return").
>
> But that's okay, because PHP *does* see both, and it tells you "yield may
not be used with return" in a lovely little parser error.  Some developers
consider this a useful hint.

-Sara
Stas Malyshev | 26 Jul 02:20 2012

Re: [PHP-DEV] Generators in PHP

Hi!

> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
> 
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.

Some notes on the RFC:
1. I think we should support rewind() by just creating a new generator
instance (i.e. doing the same that is done when generator is called for
the first time). If it depends on the resource that generator changes as
a side effect, so be it. rewindable() looks like unnecessary
complication which IMHO will not be useful in most cases.

2. I understand the pre-yield code is called on current(). What about
key()? I think it makes sense to call it there too - i.e. pre-yield code
is called whenever first key() or current() - it should be made explicit.

3. return values. I think non-empty return in generator should produce a
notice or E_STRICT.

4. What happens to the state variables when generator is cloned? Just
addref or real cloning for objects?

5. Are multiple yields allowed? I.e. the rfc mentions something like
yield yield $a - what that would mean? I'd allow yield only be applied
to variable expression (lval) because double yield doesn't make sense to
me, but maybe I miss something.

(Continue reading)

Nikita Popov | 27 Jul 20:09 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Thu, Jul 26, 2012 at 2:20 AM, Stas Malyshev <smalyshev <at> sugarcrm.com> wrote:
> Hi!
>
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>
> Some notes on the RFC:
> 1. I think we should support rewind() by just creating a new generator
> instance (i.e. doing the same that is done when generator is called for
> the first time). If it depends on the resource that generator changes as
> a side effect, so be it. rewindable() looks like unnecessary
> complication which IMHO will not be useful in most cases.

I think the best thing to do is neither. I.e. don't support rewinding
and also don't provide a rewindable() function. I think that the
concept of generators implies that it is a one-time data stream.
Rewinding would fight the very nature of the concept. I think the
currently implemented behavior of rewind() being a no-op is okay, but
one could obviously also throw an exception when rewind() is called
more than once, to make errors easier to see.

> 2. I understand the pre-yield code is called on current(). What about
> key()? I think it makes sense to call it there too - i.e. pre-yield code
> is called whenever first key() or current() - it should be made explicit.

All the Iterator functions (and send()) will move to the first yield
before performing their respective action. This is also mentioned in
(Continue reading)

Nikita Popov | 8 Aug 22:14 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov <nikita.ppv <at> gmail.com> wrote:
>> 5. Are multiple yields allowed? I.e. the rfc mentions something like
>> yield yield $a - what that would mean? I'd allow yield only be applied
>> to variable expression (lval) because double yield doesn't make sense to
>> me, but maybe I miss something.
>
> yield yield $a would basically first yield $a and then receive some
> value (via send) and yield that value again. Nothing you'd normally do
> ;) It was mentioned only as a syntax ambiguity consideration.
>
> Actually I added some additional parenthesis requirements for yield.
> For example you'd have to write the above as `yield (yield $a)` now
> (which should be slightly more clear). I haven't yet reflected this
> change in the RFC, but I'll add a section on it later.
>
>> 6. “Sending values” section seems to be missing. Especially useful would
>> be to cover what happens with keys there and what is the syntax there -
>> is it just "$a = yield;"? Or does it mean when yield is used in
>> expression it becomes incoming yield? And, last but not least - do we
>> need sending into generators at all?
>
> Yeah, I haven't written that section yet. But it is fairly simple: If
> you go $generator->send($foo) then $foo will be the result of the
> current `yield` expression. And yes, this also works with keys and
> values. All of the following are valid:
>
>     $data = yield;
>     $data = (yield $value);
>     $data = (yield $key => $value);
>
(Continue reading)

Andrew Faulds | 8 Aug 22:27 2012

Re: [PHP-DEV] Generators in PHP

On 08/08/12 21:14, Nikita Popov wrote:
> On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov <nikita.ppv <at> gmail.com> wrote:
>>> 5. Are multiple yields allowed? I.e. the rfc mentions something like
>>> yield yield $a - what that would mean? I'd allow yield only be applied
>>> to variable expression (lval) because double yield doesn't make sense to
>>> me, but maybe I miss something.
>> yield yield $a would basically first yield $a and then receive some
>> value (via send) and yield that value again. Nothing you'd normally do
>> ;) It was mentioned only as a syntax ambiguity consideration.
>>
>> Actually I added some additional parenthesis requirements for yield.
>> For example you'd have to write the above as `yield (yield $a)` now
>> (which should be slightly more clear). I haven't yet reflected this
>> change in the RFC, but I'll add a section on it later.
>>
>>> 6. “Sending values” section seems to be missing. Especially useful would
>>> be to cover what happens with keys there and what is the syntax there -
>>> is it just "$a = yield;"? Or does it mean when yield is used in
>>> expression it becomes incoming yield? And, last but not least - do we
>>> need sending into generators at all?
>> Yeah, I haven't written that section yet. But it is fairly simple: If
>> you go $generator->send($foo) then $foo will be the result of the
>> current `yield` expression. And yes, this also works with keys and
>> values. All of the following are valid:
>>
>>      $data = yield;
>>      $data = (yield $value);
>>      $data = (yield $key => $value);
>>
>> The first case is the most common though. I.e. you usually use it
(Continue reading)

Nikita Popov | 8 Aug 22:42 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Wed, Aug 8, 2012 at 10:27 PM, Andrew Faulds <ajf <at> ajf.me> wrote:
> Hi Nikita,
>
> I notice you require brackets round yield $k => $v and yield $v. Is this the
> formal syntax, i.e. '(' T_YIELD var => var ')'? If so it makes sense in a
> way, but it feels a little hackish. Does yield $v cause some sort of parsing
> issue that putting it in brackets solves? I realise that it's less
> ambiguous, but I don't like the idea of it. PHP's syntax has enough special
> cases already IMO.

Without parenthesis their behavior in array definitions and nested
yields is ambigous:

array(yield $key => $value)
// can be either
array((yield $key) => $value)
// or
array((yield $key => $value))

yield yield $key => $value;
// can be either
yield (yield $key) => $value;
// or
yield (yield $key => $value);

Apart from that particular case there is the general operator
precedence inclarity, e.g.

yield $foo . $bar;
// could be
(Continue reading)

Morgan L. Owens | 9 Aug 05:55 2012
Picon

Re: Re: [PHP-DEV] Generators in PHP

On 2012-08-09 08:42, Nikita Popov wrote:
>
> Without parenthesis their behavior in array definitions and nested
> yields is ambigous:
>
> array(yield $key => $value)
> // can be either
> array((yield $key) => $value)
> // or
> array((yield $key => $value))
>
> yield yield $key => $value;
> // can be either
> yield (yield $key) => $value;
> // or
> yield (yield $key => $value);
>
> Apart from that particular case there is the general operator
> precedence inclarity, e.g.
>
> yield $foo . $bar;
> // could be
> (yield $foo) . $bar;
> // or
> yield ($foo . $bar);
>
Is this complicating yield a bit too much? All these ambiguities would 
go away if 'yield' had the same grammatical status as 'return' - in 
other words, if it were treated as a control-flow keyword rather than as 
an operator.
(Continue reading)

Morgan L. Owens | 10 Aug 02:53 2012
Picon

Re: [PHP-DEV] Generators in PHP

Mike Ford wrote:
 >
 > The signposting needn't even be as in-your-face as a generator
 > keyword (either instead of or in addition to function): I could get
 > behind a variation such as:
 >
 > function f($x, $y) yields { ... yield $z; ... }
 >
 > Or even (stretching a bit to re-use an existing keyword!):
 >
 > function f($x, $y) return { ... yield $z; ... }
 >
 > Although I like the concept of generators, I would be -1 for any
 > implementation that doesn't differentiate them in some way from
 > regular functions.
 >
In other words you want to have return-value type-hinting _in one 
specific instance_: when calling f() returns a Generator object.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Stas Malyshev | 8 Aug 22:43 2012

Re: [PHP-DEV] Generators in PHP

Hi!

> https://wiki.php.net/rfc/generators#yield_keyword
> https://wiki.php.net/rfc/generators#sending_values

I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;

Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?

I would also not support array((yield $key => $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.

Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());

We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
(Continue reading)

Andrew Faulds | 8 Aug 22:55 2012

Re: [PHP-DEV] Generators in PHP

On 08/08/12 21:43, Stas Malyshev wrote:
> Hi!
>
>
>> https://wiki.php.net/rfc/generators#yield_keyword
>> https://wiki.php.net/rfc/generators#sending_values
> I'm not sure $data = (yield $value) makes a lot of sense. Why we have
> two variables here? Why it is only operator in the language that
> requires parentheses around? All these complex parentheses rules seem
> unnecessarily complicated. I'd rather do it in a more simple way: yield
> in an expression means incoming yield. I.e.:
> $data = yield;
> foo(yield, 1, 2);
> list($a, $b) = yield;
>
> Same with:
> call(yield $value) - what is the meaning of $value here? Why not just
> call(yield)?
>
> I would also not support array((yield $key => $value)) - it seems to be
> really unclear how it works. I'd just have yield produce a value which
> was sent, and that's it, and you could use this value in the same way
> you'd use any other expression.
>
> Only question I have here is what happens if you use yield in the middle
> of function call expression, for example:
> call(foo(bar(), $foo, yield, 3), baz());
>
> We are kind of stopping the function in the middle of the function call
> and going to unrelated code here, and may never return back. Where the
(Continue reading)

Nikita Popov | 9 Aug 17:58 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Wed, Aug 8, 2012 at 10:55 PM, Andrew Faulds <ajf <at> ajf.me> wrote:
> Hmm. This is just a quick thought:
>
> Considering the yield syntax will vary about needing () round it, why not
> make it a "fake" function (language construct).
>
> This way it's consistent: yield(), yield($v), yield($k => $v), $a = yield(),
> etc.
>
> (yield $x) is just messy as an expression. We don't have (isset $x), we have
> isset($x).

There are two reasons why I would not choose that syntax:

1. This would make "yield" look like a functions, without actually
being a function. PHP has done this in the past quite often and I
think it was a mistake. It is the reason why people try to write
empty(someCall()). It looks like a function, so they expect it to
behave like one. Similarly you also can't do $f = 'empty'; $f($foo),
which again is confusing to people new to the language.

2. Other languages that implement generators also use the "yield $foo"
syntax (and also have the same parentheses requirements). So this
makes PHP consistent with them.

Nikita

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Andrew Faulds | 9 Aug 17:59 2012

Re: [PHP-DEV] Generators in PHP

On 09/08/12 16:58, Nikita Popov wrote:
> On Wed, Aug 8, 2012 at 10:55 PM, Andrew Faulds <ajf <at> ajf.me> wrote:
>> Hmm. This is just a quick thought:
>>
>> Considering the yield syntax will vary about needing () round it, why not
>> make it a "fake" function (language construct).
>>
>> This way it's consistent: yield(), yield($v), yield($k => $v), $a = yield(),
>> etc.
>>
>> (yield $x) is just messy as an expression. We don't have (isset $x), we have
>> isset($x).
> There are two reasons why I would not choose that syntax:
>
> 1. This would make "yield" look like a functions, without actually
> being a function. PHP has done this in the past quite often and I
> think it was a mistake. It is the reason why people try to write
> empty(someCall()). It looks like a function, so they expect it to
> behave like one. Similarly you also can't do $f = 'empty'; $f($foo),
> which again is confusing to people new to the language.
yield(), so far as the programmer is concerned, might as well be a 
function. It isn't, strictly speaking, but like other function calls, it 
suspends execution of the function until the called function completes.

So I don't think this is a problem.
> 2. Other languages that implement generators also use the "yield $foo"
> syntax (and also have the same parentheses requirements). So this
> makes PHP consistent with them.
Doesn't mean we can't lead the way and have a nicer syntax :)
> Nikita
(Continue reading)

Nikita Popov | 9 Aug 19:39 2012
Picon

Re: [PHP-DEV] Generators in PHP

On Thu, Aug 9, 2012 at 5:59 PM, Andrew Faulds <ajf <at> ajf.me> wrote:
> yield(), so far as the programmer is concerned, might as well be a function.
> It isn't, strictly speaking, but like other function calls, it suspends
> execution of the function until the called function completes.
>
> So I don't think this is a problem.

I definitely can see that yield() is a plausible syntax, but I still
think that the normal yield notation is better suited. Another reason
is the following:

PHP has several constructs with a yield-like syntax. Examples are
"include $file" (and require etc) and "print $string". Both are
keyword expressions, so they are rather similar to yield.

On the other hand there are also other constructs which use the
function notation. Like isset(), empty(), etc.

The main distinction between them is their primary use: Both include
and print are usually used as statements, not as expressions. Writing
$foo = include "bar"; is something you rarely do. So here the
friendlier keyword notation is chosen. isset() and empty() on the
other hand are pretty much always used as expressions (they really
don't make sense as statements). So the function-like syntax is chosen
here, because it causes less ambiguities.

For yield the same applies. Yield will be primarily used as a
statement. The vast majority of cases will just be

    yield $someValue;
(Continue reading)

hakre | 9 Aug 23:22 2012
Picon

Re: [PHP-DEV] Generators in PHP


> Also, currently yield looks very similar to return and I think this is
> a nice thing as it is similar semantically. yield($foo) would give it
> different semantics, imho.

I love this point a lot. Return is very common and yield is some kind of return.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Morgan L. Owens | 10 Aug 03:01 2012
Picon

Re: [PHP-DEV] Generators in PHP

hakre wrote:

 >> Also, currently yield looks very similar to return and I think this
 >> is a nice thing as it is similar semantically. yield($foo) would
 >> give it different semantics, imho.
 >
 > I love this point a lot. Return is very common and yield is some
 > kind of return.
 >
I agree also: yield behaves far more like a return statement than a 
function call. (In a sense, a yield is a return that doesn't discard the 
current function's execution state.)

Which (as it happens) reminds me of the difference between
return $foo;
and
return ($foo);

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Gmane