Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?

E.g., instead of:

suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();

... we could write:

suspend(function* (resume) {
['foo', 'bar'].forEach(function(word) {
yield setTimeout(resume, 1000);
console.log(word);
});
})();

The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array,
GeneratorFunction)` with `yield*` in the body.

On Mon, Jul 15, 2013 at 11:33 AM, Claus Reinke <claus.reinke at talk21.com>wrote:

> [prompted by this nodejs list thread "Weird error with generators (using
> suspend or galaxy)"
> https://groups.google.com/**forum/#!topic/nodejs/**9omOdgSPkz4<https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4>]
>
> 1. higher order functions are used to model control structures
>
> 2. generators/yield are designed to allow for suspend/resume
>    of control structure code
>
> These two statements come in conflict if one considers the restriction
> that generators be based on flat continuations, which is sufficient to
> span built-in control structures like "for" but not predefined control
> structures like "forEach". The support for nested generators ("yield*")
> differs from normal function call operation.
>
> I have not seen this conflict discussed here, so I wanted to raise it
> in case it was an oversight and something can be done about it. As
> far as I can tell, there are two issues:
>
> - current predefined operations like "forEach", "map", "filter", ..
>    are not fully integrated with generators, even though they
>    model synchronous operations; expecting users to duplicate
>    their functionality for use with generators seems wrong;
>
> - is it even possible to define higher-order operations that can be
>  used both normally (without "yield" inside their callbacks, without
>    "yield" wrapping their result) and with generators (with "yield"
>    inside their callbacks, with "yield" wrapping their result)?
>
> Claus
> http://clausreinke.github.com/
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130715/42a749b3/attachment.html>

Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?

E.g., instead of:

```js
suspend(function* (resume) {
  yield setTimeout(resume, 1000);
  console.log('foo');
  yield setTimeout(resume, 1000);
  console.log('bar');
})();
```

... we could write:

```js
suspend(function* (resume) {
  ['foo', 'bar'].forEach(function(word) {
    yield setTimeout(resume, 1000);
    console.log(word);
  });
})();
```

The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array, GeneratorFunction)` with `yield*` in the body.