Correct me if I'm wrong, but wouldn't the lexical-scoping restraint satisfy the shallow generator requirement? As I understand it, the issue with deep generators and CPS transformations is that the transformations have to be applied to functions that aren't even lexically inside the GeneratorFunction. Additionally, can't the nested CPS transformations issue by alleviated with a reference to the GeneratorFunction stack frame itself (a la SpiderMonkey)?
On Mon, Jul 15, 2013 at 12:45 PM, Mark S. Miller <[email protected]> wrote: > This would make generators deep, violating the non-interleaving > assumptions of intermediate callers on the call stack. This is why we > accepted generators only on condition that they be shallow. We knew at the > time that this privileges built-in control structures over user defined > ones. The alternative would have been to omit generators completely. We > agree that shallow generators were worth it, despite this non-uniformity. > > Put another way, shallow generators are equivalent to a local cps > transform of the generator function itself. Deep generators would require > the equivalent of CPS transforming the world -- violating the stateful > assumptions of existing code. > > > > On Mon, Jul 15, 2013 at 9:09 AM, Jeremy Martin <[email protected]> wrote: > >> 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 >> <[email protected]>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 >>> [email protected] >>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>> >> >> >> >> -- >> Jeremy Martin >> 661.312.3853 >> http://devsmash.com >> @jmar777 >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
