.next('yo') in newborn generators
On Jan 15, 2014, at 8:32 AM, David Bruant wrote:
From what I understand, the spec says an error should be thrown because the generator is in "suspendedStart" state and value is not undefined (25.3.3.2 GeneratorResume step 7).
Yes, that's what the spec, requires. This check was in the the original Generator proposal harmony:generators#internal_methodsend
It's an error because there is no mechanism for a generator to receive the argument passed by the first next.
Sounds good. Bugs on V8 and regenerator for those interested: code.google.com/p/v8/issues/detail?id=3099, facebook/regenerator#76
Digging up old threads, but is there a way to test for newborn generators? To my knowledge they are the only iterable that does not allow a value to be passed in at a specific time.
Bradley Meck wrote:
Digging up old threads, but is there a way to test for newborn generators?
No.
To my knowledge they are the only iterable that does not allow a value to be passed in at a specific time.
What do you mean by "does not allow"?
take for example a function that accepts an iterator:
function test(name, iterable) {
try {
var iterator = iterable[Symbol.iterator]();
console.log(name,'with value for first next', iterator.next(1))
}
catch(e) {
console.error(name,'failed value for first next', e);
}
}
var arr = [1,2];
var set = new Set({first:true},{second:true});
var str = 'ab';
var gen=function*(){
yield 1;
yield 2;
};
test('array', arr);
test('set', set);
test('string', str);
test('generator', gen());
If I am reading the spec right (and I may not be), only the generator should fail? The first call to gen().next(value) must have value be undefined, and the others do not check.
Bradley Meck wrote:
If I am reading the spec right (and I may not be), only the generator should fail? The first call to gen().next(value) must have value be undefined, and the others do not check.
I thought we agreed at the January 28 meeting to get rid of this error, but I can't find it in the notes. The January meeting notes have missed other conclusions, though. Allen?
rwaldron/tc39-notes/blob/master/es6/2014-01/jan-28.md#concensusresolution "BN: Have to go back and think more about this. Maybe a helper function can be created." It looks like no ferm decision has been made yet.
Linking to some Twitter discussion related to this:
I don't see the point of throwing an error when calling .next('foo') on a newborn generator. We don't throw an error on .next('foo', 'bar'), and unlike the case with most function calls there is no way to get the 'bar' when resuming a generator, as you don't have an arguments object.
I would punt on this issue entirely, and ideally remove the "suspendedStart" state from the spec, renaming "suspendedYield" to simply "suspended".
Just MHO :)
I agree, and I thought we agreed at the last TC39 meeting, but I was wrong or else it got lost.
We'll settle it at the early April meeting.
I think we can settle this now.
Lets allow an argument.
Fine by me. I'd be happy to make the change now and confirm it at the next meeting. I'm not expecting any push back.
Playing with the test cases of the regenerator project, I came across a case and was wondering what the intention of the spec is given that Firefox and Chrome recent implementations diverge. Apologies for not reading all the previous discussions on this edge case.
Test case:
function *gen(x) { yield x; } var g = gen('whatever'); console.log(g.next(0));
Chrome & regenerator:
Firefox (Aurora 28):
From what I understand, the spec says an error should be thrown because the generator is in "suspendedStart" state and value is not undefined (25.3.3.2 GeneratorResume step 7). Where do I file bugs?