.next('yo') in newborn generators

# David Bruant (10 years ago)

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:

{value: "whatever", done: false}

Firefox (Aurora 28):

TypeError: attempt to send 0 to newborn generator

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?

# Allen Wirfs-Brock (10 years ago)

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.

# David Bruant (10 years ago)

Sounds good. Bugs on V8 and regenerator for those interested: code.google.com/p/v8/issues/detail?id=3099, facebook/regenerator#76

# Bradley Meck (10 years ago)

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.

# Brendan Eich (10 years ago)

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"?

# Bradley Meck (10 years ago)

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.

# Brendan Eich (10 years ago)

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?

# David Bruant (10 years ago)

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.

# Bradley Meck (10 years ago)

Linking to some Twitter discussion related to this:

twitter.com/bradleymeck/status/436371508005326850

# Andy Wingo (10 years ago)

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 :)

# Brendan Eich (10 years ago)

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.

# Erik Arvidsson (10 years ago)

I think we can settle this now.

Lets allow an argument.

# Allen Wirfs-Brock (10 years ago)

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.