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
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
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
Re: [PHP-DEV] Generators in PHP
On Thu, Aug 9, 2012 at 5:59 PM, Andrew Faulds 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; The expression use is just secondary here. And even there the value-less yield (the one that does not need parens) is the most common case: $data = yield; The case where you want to both receive and send at the same time is rather rare (mostly for trampoline patterns or task scheduling). So I think we should not sacrifice the most common cases for slightly better syntax in the rare cases. 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. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Aug 8, 2012 at 10:55 PM, Andrew Faulds 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
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
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.
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).
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Aug 8, 2012 at 10:27 PM, Andrew Faulds 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
(yield $foo) . $bar;
// or
yield ($foo . $bar);
This obviously is not a problem per-se, but with yield-style unary
operators the precedence rules are often hard to figure out. E.g. most
people would probably think that
if (include('foo.php') == true) { ... }
would be check the return value of include, but it's actually not.
Rather it includes the file ('foo.php') == true, which is ''.
Another issue was a purely implementational: In order to support
by-ref yielding I have to distinguish between variable and
non-variable expressions, which breaks the usual precedence rules. I
was not able to fix the shift/reduce conflicts that are created by
this without requiring the parenthesis.
Also I'd like to mention that Python also has the paren-requirement
for yield-expressions. It even requires parens for a simple yield,
i.e. you'd have to write "data = (yield)". This is not necessary in
PHP, because PHP has semicolons.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 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
either as a generator or a reverse generator, not both. But doing both
is also common for cooperative multitasking etc.
Regarding the last question: I think the feature is worth adding. It
is a very powerful concept that is hard to implement otherwise. Useful
in particular for things like parsing and multitasking.
6. What happens if you send into a by-ref generator? Is the data sent
by-ref then? What if it's an expression that can't be send by-ref?
No, sending is always by-value. By-ref only affects the yielding part.
I now added the mentioned sections:
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I also added a list of error conditions:
https://wiki.php.net/rfc/generators#error_conditions
Sorry for the delay,
Nikita
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.
Regards,
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov 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 > either as a generator or a reverse generator, not both. But doing both > is also common for cooperative multitasking etc. > > Regarding the last question: I think the feature is worth adding. It > is a very powerful concept that is hard to implement otherwise. Useful > in particular for things like parsing and multitasking. > >> 6. What happens if you send into a by-ref generator? Is the data sent >> by-ref then? What if it's an expression that can't be send by-ref? > > No, sending is always by-value. By-ref only affects the yielding part. I now added the mentioned sections: https://wiki.php.net/rfc/generators#yield_keyword https://wiki.php.net/rfc/generators#sending_values I also added a list of error conditions: https://wiki.php.net/rfc/generators#error_conditions Sorry for the delay, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Thu, Jul 26, 2012 at 2:20 AM, Stas Malyshev 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 the RFC: > If the generator is not yet at a ''yield'' statement (i.e. was just created > and not yet used as an iterator), then any call to ''rewind'', ''valid'', > ''current'', > ''key'', ''next'' or ''send'' will resume the generator until the next > ''yield'' > statement is hit. > 3. return values. I think non-empty return in generator should produce a > notice or E_STRICT. Non-empty return values currently throw an E_COMPILE_ERROR. I think that's okay as doing `return $foo` in a generator is clearly some kind of bug. In the future, should yield delegation be implemented, the return value would become meaningful again, as it would be the result of the delegation instruction. This is important for coroutine-based parsing code, so that you can write $result = yield* $this->parseSomething();. > 4. What happens to the state variables when generator is cloned? Just > addref or real cloning for objects? Cloning currently just uses addref everywhere. I'm not really sure what the right behavior is in that situation. Generally I think that cloning a generator is a rather strange thing to do, so it might make sense to drop cloning-support altogether. At least I can't really imagine a use case for it. > 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 either as a generator or a reverse generator, not both. But doing both is also common for cooperative multitasking etc. Regarding the last question: I think the feature is worth adding. It is a very powerful concept that is hard to implement otherwise. Useful in particular for things like parsing and multitasking. > 6. What happens if you send into a by-ref generator? Is the data sent > by-ref then? What if it's an expression that can't be send by-ref? No, sending is always by-value. By-ref only affects the yielding part. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
2012/7/26 Bernhard Schussek : [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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
I too don't think that a new keyword is necessary for this case. Let's
not forget that it is a common practice to document functions with doc
blocks, which further helps understanding what it does.
/**
* @return Generator
* @yield string
*/
function generate() {
...
yield $foo;
...
}
Cheers,
Bernhard
2012/7/26 Alex Aulbach :
> 2012/7/26 Yahav Gindi Bar :
>> "yielder" sounds quite weird don't you think (but my native language is not
>> English too.. so don't blame me at english stupid conclusions!)
>>
>>> Fact: generator is not a good keyword, because too common.
>> I can't see the connection... people relate the generator keyword to the
>> iterators so what's the problem using it?
>
> PHP will just complain in existing scripts if you use "generator" as
> function-name and stops compiling. I think this is stupid, but that's
> a completly different discussion.
>
>> what about using the "iterator" name as generators keyword? because it does
>> return iterators...
>
> well, wouldn't think, that it can be that easy.
>
>> iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning
>> too.
>> though it can confuse some people with the original iterators...
>
> But it's just what it does.
>
>> BTW: I still don't think that the generators need a unique word and I
>> suggest using functions, but I didn't read al the mails chain, so I assume
>> that I'll find there the answer.
>
> Of course you will!
> These are not the droids your looking for. Ups. wrong line.
> :)
>
>
> --
> Alex Aulbach
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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. 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? 6. What happens if you send into a by-ref generator? Is the data sent by-ref then? What if it's an expression that can't be send by-ref? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
2012/7/26 Yahav Gindi Bar :
> "yielder" sounds quite weird don't you think (but my native language is not
> English too.. so don't blame me at english stupid conclusions!)
>
>> Fact: generator is not a good keyword, because too common.
> I can't see the connection... people relate the generator keyword to the
> iterators so what's the problem using it?
PHP will just complain in existing scripts if you use "generator" as
function-name and stops compiling. I think this is stupid, but that's
a completly different discussion.
> what about using the "iterator" name as generators keyword? because it does
> return iterators...
well, wouldn't think, that it can be that easy.
> iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning
> too.
> though it can confuse some people with the original iterators...
But it's just what it does.
> BTW: I still don't think that the generators need a unique word and I suggest
> using functions, but I didn't read al the mails chain, so I assume that I'll
> find there the answer.
Of course you will!
These are not the droids your looking for. Ups. wrong line. :)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 26 ביול 2012, at 01:22, Alex Aulbach wrote:
> 2012/7/25 Nikita Popov :
>> particular with namespaced code). So if you have some kind of
>> Code\Generator class, you're screwed.
>> Keywords don't grow on trees, you know ;)
>
> Hm. Ok, thats a problem.
> Oh, man, do I really have to find a good keyword myself? Maybe we
> should use a password-generator. :)
> Seriously, how's about
>
> yielder hugo() { ... yield ...}
>
> Feels right, but my native language is not english, so I risk to make
> me a fool. I think that also names what it really is: A yielder yields
> something. In this case: An iterator yielder yields an iteration. I
> think I would like that.
> And the word is per sure not common. :)
> Ahmm, if you don't like it, would you be so kind to make a suggestion? TNX
>
>> Also I'd like to point out that being similar to other languages is in
>> the general case a *good* thing. So if you say "It doesn't matter how
>
> In general I agree. For PHP I do not. This case is a little bit
> different, because the targets are self-explaining and simplicity.
>
>> Deviating from the
>> "standard" generator implementation without having good reasons seems
>> rather pointless to me.
>
> But I gave good other reasons. :)
>
>
>
> Conclusion:
> ==
>
> Fact: generator is not a good keyword, because too common.
>
> Answer: I made a new sugestion with the keyword "yielder".
>
> Fact: in general it's a good idea to implement features, like in other
> languages.
>
> A: Correct, but
>
> Fact: PHP has different architectural targets which doesn't mean to
> make everything different, but ...
> Experience: in this case I'm sure, it's not the best way to make it
> like any other language.
> Experience: If you have enough reasons to make things different, don't
> look too much how others are doing.
> Experience: Most PHP-programmers are not so experienced like most
> programmers in other languages.
> (Can't be proven, but I would bet for it.)
>
> --
> Alex Aulbach
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Wow, I wasn't near my computer for the last day and I see that the conversation
really grew ;)
"yielder" sounds quite weird don't you think (but my native language is not
English too.. so don't blame me at english stupid conclusions!)
> Fact: generator is not a good keyword, because too common.
I can't see the connection... people relate the generator keyword to the
iterators so what's the problem using it?
what about using the "iterator" name as generators keyword? because it does
return iterators...
iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning
too.
though it can confuse some people with the original iterators...
BTW: I still don't think that the generators need a unique word and I suggest
using functions, but I didn't read al the mails chain, so I assume that I'll
find there the answer.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP-DEV] Generators in PHP
On Tue, Jun 12, 2012 at 11:07 PM, Ángel González 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
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
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 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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: > > "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 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 >> 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 wrote: On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 > 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 >> > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ >>> >>> >>> >>> -- >>> Laruence Xinchen Hui >>> http://www.laruence.com/ >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 > 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 wrote: >>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 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 > -- Laruence Xinchen Hui http://www.laruence.com/ >>> >>> >>> >>> -- >>> Laruence Xinchen Hui >>> http://www.laruence.com/ >> >> >> >> -- >> Laruence Xinchen Hui >> http://www.laruence.com/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 wrote: >> On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 >>> 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 >>> >>> >>> >>> -- >>> Laruence Xinchen Hui >>> http://www.laruence.com/ >> >> >> >> -- >> Laruence Xinchen Hui >> http://www.laruence.com/ > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 @ Hoa 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 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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);
}
And you could also change the yield_next pointer in foo_bar() to avoid
going through goto's or switch statements. Possibly yield_next could be
take the arg with double indirection and you could also completely
replace the context.
I understand this has the problem that the internal and userspace
implementations would be markedly different.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Thu, Jun 7, 2012 at 10:46 AM, Gustavo Lopes 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
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin @ Hoa
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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. 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. Well, the Iterator::rewind() docs say that rewind() rewinds the iterator. If this is not possible, then Iterator should not be implemented. See http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8 In the same order, your options are: 1. As changing Iterator is not possible, have a new interface, say, BasicIterator from which Iterator will inherit without rewind(). 2. Make all the Generators rewindable (possibly by fetching a new generator each time). 3. Do not implement Iterator. (By the way, if you implement Traversable, one you can always use the unsafe IteratorIterator to get access to the methods) * Exceptions can be thrown from generators as always. * Not sure what you mean by "generator returns function". What would be that problem with that? 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? * Generators can be methods, as shown in the example in the Introduction section. Closures can also be generators. Can other callable classes be generators? Are you planning on any internal API for functions to implement generators (though I really haven't thought how that would work)? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
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
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 10:55 AM, Gustavo Lopes 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?
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 10:09 AM, Nikita Popov wrote: > On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig 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 whether or not generators will add any functionality that can't already be accomplished (albeit somewhat more clumsily) via closures. I tend to think the answer to that probably lies in yields, but I think it would be beneficial to address this-- along with some examples to illustrate this advantage over closures in appropriate use-cases-- in the RFC. I agree with Stas that, while it's a great idea, the RFC itself is far from complete. > > > What release version do you believe should be targetted for this? > The next major version, i.e. PHP 5.5. > Ok good. Just wanted to make sure we weren't talking about squeezing this into 5.4 lol. Personally, I think RFCs should specify the target PHP version when applicable. I know it's not required but I think it'd be a good idea to get in that habit anyway IMHO. --Kris > > Nikita >
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 4:15 AM, Laruence 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
Re: [PHP-DEV] Generators in PHP
On Tue, Jun 5, 2012 at 8:52 PM, Benjamin Eberlei wrote:
> This is really awesome. Some remarks:
>
> 1. The * looks a bit hidden. How about reusing the yield keyword? "function
> yield getLines()"
I mainly chose the * modifier because this is how JavaScript
(ECMAScript Harmony) does it. It also seemed to convey the idea of
returning multiple values well (Cleene star). But I wouldn't have much
of a problem using some other keyword. As already written in the RFC
"generator" is problematic as it is not an uncommon word. I wouldn't
like reusing "yield" as it doesn't make much sense semantically there
(if you read "function yield xyz()" out). What seems plausible is
using a separate keyword "yielding", so you have a "yielding function
xyz()".
> 2. Any comments about iterator vs closure?
>
> function getLinesFromFile($fileName, Closure $yield) {
> //..
>
> while (false !== $line = fgets($fileHandle)) {
> $yield($line);
> }
> // ..
> }
>
Yes, using callbacks is indeed a common approach to work around the
lack of generators. The problems with the callback approach (and
several other alternatives) is outlined very well in the first few
paragraphs of PEP 255 (http://www.python.org/dev/peps/pep-0255/).
Basically the issue is that without using generators either the
producer (here getLinesFromFile) or the consumer (here the main code)
has to manually keep track of it's current state. Depending on the
complexity of the producer/consumer this can become very hard, which
can be especially well seen in the tokenizer/parser examples given in
the aforementioned PEP. When using generators on the other hand the
state is implicitly maintained by the VM, so the programmer doesn't
have to worry about that anymore.
So basically, yes, callbacks can be used for the simpler applications
of generators, but with more complex problems they can quickly become
very messy.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig 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
Re: [PHP-DEV] Generators in PHP
On 06/06/12 12:20, Ivan Enderlin @ 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
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
Ingénieur Logiciel
2012/6/6 Ivan Enderlin @ Hoa
> 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/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 wrote: > On 06/06/2012 04:42 AM, Laruence wrote: >> On Wed, Jun 6, 2012 at 10:27 AM, Laruence wrote: >>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 account. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 wrote: >> On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 10:27 AM, Laruence wrote: > On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 >> 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 >>> >> >> >> >> -- >> Laruence Xinchen Hui >> http://www.laruence.com/ > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Jun 6, 2012 at 10:15 AM, Laruence 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 > 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 >> > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Tue, Jun 5, 2012 at 10:35 AM, Nikita Popov 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 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). 2. In what way(s) do you believe this approach would differ from inline functions and what advantage(s) do you see in those differences? 3. What release version do you believe should be targetted for this? --Kris
