On May 13, 2013, at 9:44 PM, Brendan Eich wrote:

> David Herman wrote:
>> On May 13, 2013, at 6:11 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> 
>>> Merge next and send by letting next take an optional parameter? Ok by me.
>> 
>> +1
> 
> I pointed out to Dave that Python has arity checking and did next before adding send in 2.5 for "coroutines", whereas JS has optional params without arity checking, so folding send into next works.
> 
>>> Make yield* work on any {next, throw}, not necessary but ok by me too.
>> 
>> Yes with one delta: if there's no .throw it still works, it just defaults to (x) =>  { throw x }. This way you can write ordinary iterators without having to worry about providing the default throw, and they still function properly as generators.
> 
> +1 or more -- we should not invent new nominal types with stub throw method implementations, people will not use them and they are unnecessary boilerplate.
> 
> /be
> 


All sounds fine with me and I've updated the draft accordingly.

What about providing a convenience "resume" method on generators to help clarify co-routine style usage?  Dave suggested that "resume" was pedagogically useful.

I would define it equivalently two:

   resume(...args) {return this.next(...args};

(resume rather than next delegates to avoid the delegation for normal for-of iterations)

Allen

On May 13, 2013, at 9:44 PM, Brendan Eich wrote:

> David Herman wrote:
>> On May 13, 2013, at 6:11 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> 
>>> Merge `next` and `send` by letting next take an optional parameter? Ok by me.
>> 
>> +1
> 
> I pointed out to Dave that Python has arity checking and did `next` before adding `send` in 2.5 for "coroutines", whereas JS has optional params without arity checking, so folding `send` into `next` works.
> 
>>> Make `yield*` work on any `{next, throw}`, not necessary but ok by me too.
>> 
>> Yes with one delta: if there's no `.throw` it still works, it just defaults to `(x) => { throw x }`. This way you can write ordinary iterators without having to worry about providing the default `throw`, and they still function properly as generators.
> 
> +1 or more -- we should not invent new nominal types with stub `throw` method implementations, people will not use them and they are unnecessary boilerplate.


All sounds fine with me and I've updated the draft accordingly.

What about providing a convenience `resume` method on generators to help clarify co-routine style usage?  Dave suggested that "resume" was pedagogically useful.

I would define it equivalently two:

```js
resume(...args) {return this.next(...args)}
```

(`resume` rather than `next` delegates to avoid the delegation for normal `for`-`of` iterations)