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

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

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

--

--
Laruence  Xinchen Hui
http://www.laruence.com/

--
Laruence  Xinchen Hui
http://www.laruence.com/

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

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?

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 option.
I was thinking of the Generator as a NoRewindIterator, which also
simply does nothing when rewind() is called on it. This allows you to
start traversing the iterator in one loop and continue traversing it
in another loop:

function *allNaturalNumbers() {
    for ($i = 0; ; ++$i) {
        yield $n;
    }
}

$numbers = allNaturalNumbers();

echo 'First loop:', "\n";
foreach ($numbers as $n) {
    echo $n, "\n";
    if ($n == 3) break;
}

echo 'Second loop:', "\n";
foreach ($numbers as $n) {
    echo $n, "\n";
    if ($n == 6) break;
}

This would output:

First loop:
1
2
3
Second loop:
4
5
6

Generators in Python behave the same way. (To be fair though Python
generally has no notion of rewinding an iterator, so all
iterators in Python act like that.)

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.

In fact, if you can't implement Iterator in full, you should implement Traversable instead.
Not sure whether the lack of rewinding behavior really disqualifies it
to use the Iterator interface. I think having the internal iteration
methods exposed is quite handy, especially if you consider their use
as coroutines, where you often want to call the iteration interface
manually and not using a foreach loop.

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.
Yes, agree with that.

• 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.
  Yes, the RFC is only a stub, it's not complete yet. But to answer your
  questions:

• Exceptions can be thrown from generators as always.
• Not sure what you mean by "generator returns function". What would
  be that problem with that?
• Generators can be methods, as shown in the example in the
  Introduction section. Closures can also be generators.

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 account.
Yup, thanks for your comments!

Nikita

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
Ingénieur Logiciel

2012/6/6 Ivan Enderlin @ Hoa ivan.enderlin@hoa-project.net

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/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin @ Hoa
ivan.enderlin@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;
}
// ...
}

What this doesn't yet properly cover is the use of generators as
cofunctions. In this case it is desirable that ->send() calls are also
propagated (same applies to ->close() and the not yet implemented
->throw()).

To cover all those use-cases you'd have to come up with a rather big
and ugly block of code (you can find a Python same implementation in
http://www.python.org/dev/peps/pep-0380/#formal-semantics).

Thus it is clear that another expression is required which allows you
to delegate execution to another generator/cofunction. In Python this
is "yield from", in JavaScript "yield*".

A tree implementation using it could look like this:

class Tree implements IteratorAggregate {
protected $value, $left, $right;

public function __construct($value, Tree $left = null, Tree $right = null) {
    $this->value = $value;
    $this->left = $left;
    $this->right = $right;
}

function *getIterator() {
    if ($this->left) yield* $this->left;
    yield $this->value;
    if ($this->right) yield* $this->right;
}

}

As you can see the iterator implementation is dead simple.

(Note though that the yield* expression described above isn't yet
implemented, but I plan to implement it.)

Nikita

2012/7/20 Nikita Popov nikita.ppv@gmail.com:

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.

That's what I think will happen. I think "yield" makes it more
difficult to maintain unknown code.

I think "yield" alone is too less. I think the function should be
explicitly marked as generator function.

Stupid Suggestions:

generator function gen()
{
yield 1;
}

generator gen()
{
yield 1;
}

function generator gen()
{
yield 1;
}

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?

class gen implements generator
{
function __generator()
yield 1;
}
}

class gen extends generator
{
function __generator()
yield 1;
}
}

Calling looks for me now much less "magic":

$gen = new gen;
$gen->next();

As maintainer I see "oh, it's a magic method", it's such an iterator thingy.
Another advantage: It's not final. I could replace next() etc. with my
own implementation.
And it works more hand in hand with iterators.

Just my very primitive first thoughts as PHP-scripts-developer,
without knowing much about the implementations in other languages. :)

PS: I would like to see that yield goes hand in hand with the iterator-stuff.

PPS: Ok, maybe a change isn't really needed, but I think how to use
this in a good manner (to avoid the problems mentioned above) should
be part of the docs.

--
Regards, Alex Aulbach

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

Andrew Faulds wrote:

I top you 20 years with 37 years. I was programming in Algol in 1975
( at
Warwick university ). I'm not a programmer, I'm a hardware engineer
who has to
program to make systems work. I added PHP 12 years ago to create web
based
applications to augment c and Pascal based applications. Many of the
concepts
being added make sense only as extensions to the core code, and
don't need to
be forced into general use. Adding tools that have very specialist
use should
be done as options, which we can leave out if we want to. The it
needs to be
justified switching something on by default. I have no objection to
'new
facilities', but only if I can also switch them off ...

Eh, what? "Switch them off"?

What on earth do you mean? "use noGenerators" and then break tons of
third-party
code relying on it? Or do you think you're forced to use them?

The third party code would have to justify using them in my book. But
as long as I KNOW what a library is using then I have the option
simply to avoid it. At the moment how many third party codes are
'strict compliant' and can be used safely with PHP5.4? In my book this
is exactly the same problem. For many years all of my PHP5 code played
nicely with PHP4 installations even though I never used PHP4. Nowadays
you are saying "You can't use this until your ISP updates" - so
libraries NEED to manage this or specifically avoid features that are
not in general use 'in the wild' ... ISP are only just updating to
PHP5.3 since PHP5.4 is not generally available in the core ISP
distributions ... It's additions like this that are delaying adoption
rather than enhancing it.

I don't understand, sorry.

A feature's existence doesn't mean you're forced to use it. Did the
introduction
of short array syntax force you to use [] instead of array()?!

Until one gets thrown into libraries that use 'short array syntax'
exclusively and have to work out what the heck is going on. We don't
get forced to USE it, but we do get forced to ensure that we
understand exactly what it is doing even if we don't and it adds
unnecessarily to the library of functions we need to understand :(

Boo hoo, PHP has new features, you'll have to understand them, shock horror!

Also, PHP5 code playing nicely with PHP4? I'm pretty sure PHP4 had big,
big incompatibilities with PHP5. Although I'm too recent a PHP
programmer to have ever had to deal with that. I've only ever dealt with
PHP5. But I know that PHP4 had pass-by-value objects, and PHP5 had
pass-by-reference, so I'm surprised if PHP5 code works correctly in PHP4.

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

Andrew Faulds wrote:

I top you 20 years with 37 years. I was programming in Algol in 1975 ( at

Warwick university ). I'm not a programmer, I'm a hardware engineer who
has to
program to make systems work. I added PHP 12 years ago to create web
based
applications to augment c and Pascal based applications. Many of the
concepts
being added make sense only as extensions to the core code, and don't
need to
be forced into general use. Adding tools that have very specialist use
should
be done as options, which we can leave out if we want to. The it needs
to be
justified switching something on by default. I have no objection to 'new
facilities', but only if I can also switch them off ...

Eh, what? "Switch them off"?

What on earth do you mean? "use noGenerators" and then break tons of
third-party
code relying on it? Or do you think you're forced to use them?

The third party code would have to justify using them in my book. But as
long as I KNOW what a library is using then I have the option simply to
avoid it. At the moment how many third party codes are 'strict compliant'
and can be used safely with PHP5.4? In my book this is exactly the same
problem. For many years all of my PHP5 code played nicely with PHP4
installations even though I never used PHP4. Nowadays you are saying "You
can't use this until your ISP updates" - so libraries NEED to manage this
or specifically avoid features that are not in general use 'in the wild'
... ISP are only just updating to PHP5.3 since PHP5.4 is not generally
available in the core ISP distributions ... It's additions like this that
are delaying adoption rather than enhancing it.

some/most of the E_STRICT messages are telling you about (possible)
problems in your code.
you can decide to ignore them, but imo it is a good thing that we tell
those to the developer.
the PHP4->PHP5 transition was pretty major, I'm surprised that your "php5
code" worked on php4 just fine.
my hunch is that you only used a small subset of the language (and you
didn't used oop at all, else you would remember the php4->php5 migration
PITA), so you simply didn't noticed that back then.
PHP 5.3 is still supported, and 5.4 is pretty new (in terms of distribution
life-cycles), so imo it is perfectly fine that most distro still uses 5.3
as the latest available version.
not fixing the outstanding issues or implementing enhancments/extensions
which makes the majority of the php devs lifes easier also can be a problem
in the long run.
of course we have to find the balance, and only accept/implement reasonable
changes, which are worth the BC brakes/bloat by a big margin.

Until one gets thrown into libraries that use 'short array syntax'
exclusively and have to work out what the heck is going on. We don't get
forced to USE it, but we do get forced to ensure that we understand exactly
what it is doing even if we don't and it adds unnecessarily to the library
of functions we need to understand :(

I don't understand this reasoning. You said that you are ok with the new
features, but you should be able to turn those off.
If you have libraries which depend on the new feature, you are screwed
anyway whether you can disable it or not.
So you can either say that you don't want any change, or you should accept
the fact that with change, there is a chance that either directly or
indirectly you will be using that feature.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

2012/7/25 Andrew Faulds ajf@ajf.me:

Experience can be helpful. But you must support things with facts
Ok, I tried to bring all the pro arguments together.

Suggestion:

For a generator, rename the keyword "function" to ... "generator" or
something like that. Example:
generator hugo()
{
yield ...
}

Fact: yield/generators is more or less complicated, this shouldn't be
changed - it's a proven concept.
Fact: yield makes functions some kind of "different".
Fact: It doesn't matter how much difference and if PHP has already
"different" behaving functions. We're talking about now.
Fact: It doesn't matter how it is implemented in other languages,
because we talk about PHP and not other languages.
Fact: This is also good style in general: Call the things what they are.
Fact: as PHP-developer we must try to avoid making things more
complicated, because this is one of the best features of PHP.
Fact: it's easy to implement a new keyword into PHP for that case

Experience: Most PHP programmers will have problems to understand
generators because it is a function that generates an iterator...
something magic <eyesroll> they never heard of before.
Experience: generators/yield can't be explained on one page. Much
programmers will never ever read so much docs. :)
Experience: good features are self-explaining. A function which
returns an iterator because of a simple word in it's body is not.
Experience: They will make stupid mistakes, because they mix yield
function with normal functions.
Experience: They will make stupid mistakes, because they will look for
"return" instead for "yield".
Experience: again, yield is more or less complicated, it's in this
case not a good idea to cover complexity by using already existing
language constructs.
Experience: Not using the same name will remove a little bit pressure
from "busy" programmers
Experience: It's of course their fault, if the don't learn how to use
something. But this is against the concepts of PHP. This means: If we
have the chance to make things easier we must do it.
Experience: The current concept dosn't "feel right" for me. I like to
listen to my belly in those questions, because he is in most cases
right. With the change I suggested he stops grumbling.

Please correct me if I use arguments I thought they have been
generally agreed/some of them are new.

Alex Aulbach

Fact: Adding a new name for a special kind of function as a syntax
construct is going to cost (possibly unnecessary) time and energy,
because now you have functions, and weird things that look almost like
functions but aren't and can only be used to make generators.

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

Suggestion:

For a generator, rename the keyword "function" to ... "generator" or
something like that. Example:
generator hugo()
{
yield ...
}

As Nikita pointed out, having a T_GENERATOR token will cause side-effect
problems from namespace collisions. This is a concern any time you add a
keyword to the PHP parser.

Fact: yield/generators is more or less complicated, this shouldn't be
changed - it's a proven concept.

Speaking of parse errors, I'm having trouble parsing this line. I think
you're saying that generators are just complex things and that's the way it
should be. I... guess I agree, though I have a lower opinion on the
complexity of generators. Seem like a fairly straightforward concept to
me. They are certainly proven concepts.

Fact: yield makes functions some kind of "different".

Yes, they turn normal functions into continuation functions (functions
which can be exited and reentered dynamically).

Fact: It doesn't matter how it is implemented in other languages,
because we talk about PHP and not other languages.

Disagree somewhat. Part of PHP's ease-of-use it it's similarity to other
languages so that a developer working on C or Perl or Java or
what-have-you, can look at PHP code for the first time and have a pretty
good idea of what's going on. Mirroring existing implementations should
certainly be a consideration for that purpose. Not the end-all decider,
but a consideration.

Fact: This is also good style in general: Call the things what they are.

I'll grant this point has merit, however it has two counter-arguments. (1)
T_GENERATOR naming conflict mentioned above. (2) Generators are still
functions, so the name "function" isn't a misnomer. They're just a special
type of function similar to how methods are special types of functions, but
we still label them as "function".

Fact: as PHP-developer we must try to avoid making things more
complicated, because this is one of the best features of PHP.

Agreed. And a generator is far less complex than a full iterator
implementation. Further, continuation functionality is far less complex
than building in loop counting logic to an iterator's next() method.

Fact: it's easy to implement a new keyword into PHP for that case

False. See above.

Experience: Most PHP programmers will have problems to understand
generators because it is a function that generates an iterator...

something magic <eyesroll> they never heard of before.

Fact: PHP's manual is the best in the industry. PHP developers know this.
PHP developers are smarter than you give them credit for.

Experience: generators/yield can't be explained on one page. Much
programmers will never ever read so much docs. :)

The core of what a generator is can be explained in a single paragraph with
a few examples - Just like nearly every page in the PHP manual. If we
can't give PHP developers that much credit, then we should shut the project
down now.

Experience: good features are self-explaining. A function which
returns an iterator because of a simple word in it's body is not.

A developer who's never seen the yield keyword before need only learn what
it is once. http://php.net/yield Problem (to be) solved.

Experience: They will make stupid mistakes, because they mix yield
function with normal functions.

And the compiler will slap them for it.

Experience: They will make stupid mistakes, because they will look for
"return" instead for "yield".

And they won't find it, but hey look, what's this yield thing, I wonder
what that does: http://php.net/yield

Experience: Not using the same name will remove a little bit pressure
from "busy" programmers

Developers who work with other people's code (and that's who you're talking
about) routinely have to spend time understanding the purpose of a given
function. To assume that one can pretend to understand a function without
having seen and questioned an unfamiliar keyword like "yield" is ridiculous
from the outset.

If this hypothetical developer wants to understand the function, they'll
see it's got yield and learn that's what makes it a generator. If they
don't want to understand the function, then putting up a big sign isn't
going to help the matter whatsoever.

Experience: The current concept dosn't "feel right" for me. I like to
listen to my belly in those questions, because he is in most cases
right. With the change I suggested he stops grumbling.

Fair enough. Unfortunately, for the reasons stated above, it's just not
that simple.

I'll ask again since no one has answered ...

In a different way ...
Is the only thing that changes the 'function' into a 'generator' replacing
the call to process the data with 'yield'? ( That would be 'SUSPEND' in an
SQL procedure ) ...

So how DOES an IDE work out the flow in order to correctly check that
variables are defined?

As always, my IDE provides a lot of 'sexy' stuff so that I don't need to
have it built in to the language, and I still can't see how a lot of what is
being loaded in helps with performance which is the only thing that I am
interested in. Performance wise why is yield better than just directly
calling a function to handle the data?

Lester Caine and Alex Aulbach,

may I ask you to continue this discussion in a separate thread? I am
really interested in constructive responses about the generator RFC,
but your discussion is generating a lot of noise, which makes it very
hard for me to pick out the few mails that are of interest to me.

If you could open a new thread (like "Generator keyword") it would help a lot.

Thanks,
Nikita

2012/7/26 Bernhard Schussek bschussek@gmail.com:
[about doc-blocks]

Fact: Doc blocks are not forced by the language.
Fact: For an IDE an own keyword will help the parser to distinct
faster/easier between "normal" functions and a generator.

Experience: IDEs will have their problems implementing this - think at
first try this isn't implemented with all consequences, so they may
not be helpful to see the difference.

--
Alex Aulbach

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?

Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}

And I do: foo()->current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.

Also, small point: yield is repeatably called "statement" in the doc,
but in fact it can be both statement and expression with returning yield.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227