On Tue, Mar 3, 2015 at 10:00 PM, Domenic Denicola <[email protected]> wrote:
> That's not really the issue at hand, though. Your runner won't work with > functions that manually return generator instances, due to its > type-testing. Even if those functions return generator instances express a > perfectly valid async program sequence. > > I don't follow -- it definitely used to work (I use the past tense because I went ahead and converted to do the async fn wrapper thing instead). The type test was just to determine whether or not to flatten generator functions into generator instances, which is what the coro trampoline expects. Any generator instance can be run through that coro tramp -- even ones not designed as coroutines (not recommended, of course -- though it'd be fine so long as it terminates). I just noticed the coro tramp in the async/await spec: https://github.com/lukehoban/ecmascript-asyncawait#spawning. This is just about identical to my own, though I can't quite figure out why it bothers operating on generator functions rather than instances. It seems more natural to instantiate the generators (and their argument bindings) from within an async fn wrapper, e.g. https://github.com/deanlandolt/copromise/blob/master/copromise.js#L23. Removing the type test definitely cleaned up the API, and managed to shrink an already tiny code base even more, so it was clearly a win. But I still can't see how how type testing would have broken anything at all in the previous design.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
