>>    // this doesn't work
>>    function* generator(){
>>        [1,2,3].forEach( function(x){ yield x } )
>>    }
> I have been thinking and with for..of, I can't find a good reason to use 
> .forEach instead of for..of.
> for..of does what you need here with generators too.

Perhaps you're right that .forEach is going to die (there are also
generator expressions to consider, covering some of the other
standard methods). It was the smallest example I could think of
to illustrate the point.

However, the argument is not about a specific operation but about
being able to define such operations in user code (eg, array 
comprehensions can usually be mapped to uses of .map, .concat,
.filter; loops can be mapped to tail recursion; ...). User-defined
control structures can be extended/modified without waiting for
the language as a whole to evolve. If the equivalence between
built-in and user-defined operation is broken, that option is no
longer fully functional.

>> For the specific case of forEach et al
> What do you mean by "et al"? I don't believe .map, .reduce or .filter 
> are any interesting to use alongside generators.

And why not? Because yield is a statement, and because those
operations have not been (cannot be) extended to work with
generators. Why shouldn't I be able to traverse an array, using the
ES5 standard operations for doing so, yielding intermediate results
from the traversal (recall also that yield can return data sent in via 
.next, for incorporation into such traversals)?
 
> Even if so, for..of can work too and is decently elegant (YMMV):
> 
>     function* g(){
>         [1,2,3].map(x => {yield transform(x)})
>     }

I fell for this, too:-) arrow functions have no generator equivalents.
 
> becomes
> 
>     function* g(){
>         for(x of [1,2,3]) yield transform(x);
>     }

Methods can be replaced by built-ins. It is the reverse that
is now broken.

Claus

> I have been thinking and with for..of, I can't find a good reason to use 
> .forEach instead of for..of.
> for..of does what you need here with generators too.

Perhaps you're right that .forEach is going to die (there are also
generator expressions to consider, covering some of the other
standard methods). It was the smallest example I could think of
to illustrate the point.

However, the argument is not about a specific operation but about
being able to define such operations in user code (eg, array 
comprehensions can usually be mapped to uses of .map, .concat,
.filter; loops can be mapped to tail recursion; ...). User-defined
control structures can be extended/modified without waiting for
the language as a whole to evolve. If the equivalence between
built-in and user-defined operation is broken, that option is no
longer fully functional.

> What do you mean by "et al"? I don't believe .map, .reduce or .filter 
> are any interesting to use alongside generators.

And why not? Because yield is a statement, and because those
operations have not been (cannot be) extended to work with
generators. Why shouldn't I be able to traverse an array, using the
ES5 standard operations for doing so, yielding intermediate results
from the traversal (recall also that yield can return data sent in via 
.next, for incorporation into such traversals)?
 
> Even if so, for..of can work too and is decently elegant (YMMV):
> 
>     function* g(){
>         [1,2,3].map(x => {yield transform(x)})
>     }

I fell for this, too:-) arrow functions have no generator equivalents.
 
> becomes
> 
>     function* g(){
>         for(x of [1,2,3]) yield transform(x);
>     }

Methods can be replaced by built-ins. It is the reverse that
is now broken.