Support AGen specification for asynchronous generators

[CrabDude]

To generate discussion, feedback and achieve interoperability:

You know the details, but for anyone else coming here...

@Raynos and I put together the AGen specification with your feedback for asynchronous generators, generators + asynchrony (e.g., promises, continuables, etc...) which we're using in our own libraries (gens) to create a cohesive specification for asynchronous generator interoperability.

Some highlights:

• Asynchrony agnostic: implementor/user could support promises, thunks, or something new and exotic, but must support yielding on generator objects.
• Support for serial (vanilla yield) or parallel (yield [...]) execution.
• Separation of Errors and Exceptions

[Raynos]

Right now the AGen spec has some thought into it to handle the majority of the common use cases without external helper libraries.

If we can get some minimal interop between generator runner libraries you can start exporting generator functions on npm and use yield* functionFromOtherModule().

Feedback is welcome on what a good minimal set of runner functionality is so that generator functions exported by modules can work with multiple runners

[creationix]

I don't understand. If we can't agree no what asynchrony to use, where is the interop? A library would have to support all the possible types to be universally useful.

[Raynos]

@creationix where all possible types is currently promises & continuables. I should update gens to support promises.

We could define a third interface for all other asynchronies that everyone else that is not promises / continuables would have to define.

Maybe I should add some functionality to the AGen repo that allows you to treat arbitrary asynchrony with a simple callback api so that runner authors only have to use those functions.

[CrabDude]

@creationix Because there's no reason, need or benefit to adopting a whitelist of supported Asynchrony. If the list is large, then the spec becomes cumbersome, and if the list is small, then supporting additional types becomes trivial. If all current potential AGen implementations already support promises and continuables, it's a moot point.

What is the logic in supporting asynchrony that you don't use or consume?

[creationix]

I guess I don't understand the point of this proposal then? What's the goal here? What's the interop we're trying to gain?

[Raynos]

the aim is to define the minimum stuff needed to publish generators on npm and have them work with multiple generator runners.

We do run into the problem of "what can you yield", for which I don't have a good answer other then 'at least promises and continuables'

I did abstract that asynchrony differences stuff out into https://github.com/Raynos/gens/blob/master/asynchrony.js and have added support for promises to my thing & tests.

[CrabDude]

The lack of whitelisted Asynchrony seems to be a hangup from a feedback perspective, so perhaps we should just add thunk & promises as they're both (eventually) built-in.