How to tell function and generator function apart?

Dean Landolt dean at deanlandolt.com
Wed Mar 4 04:13:56 UTC 2015


On Tue, Mar 3, 2015 at 10:00 PM, Domenic Denicola <d at domenic.me> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150303/d7c6c9f0/attachment.html>


More information about the es-discuss mailing list