3 ms·

From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generator

From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generators. For example, var data = await downloadSomething(); function *downloadSomething() { // check somethings return await http.get('foo.com', function (result) { yield result; }); } The above won't work since the callback to http.get is not a generator. You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback. Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?

munificent 12y ago
> My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.
- saurik 12y ago
  This is only true if you are building the implementation of async/await as a compilation hack (maybe a "transpiler", as people now like to say) rather than as a feature of the virtual machine. You don't need "threads" to implement this, you just need the ability to work with multiple stacks and then have use the techniques from coroutines. (Some people call this "green threads", but that's not the kind of "threads" you would refer to when saying C# has threads.) I imagine the reason they avoided doing this was to not require browser vendors to make half their browser internals safe for usage in reasonable coroutines ;P. I can also see them having wanted to guarantee that the feature could be implemented using a transpiler rather than requiring it to be a native feature of the browser, and generators being explicitly marked at both the declaration and call sites (or async await with the limitations you mention) have that property by allowing a continuation passing transform to be applied to the generator's code. (Which could be applied to all code, of course, but not native browser code. edit: Well, you could so that as well, but it would violate other assumptions about how the code is supposed to work, and isn't something anyone has infrastructure to accomplish ;P.)
  - emn13 12y ago
    To condense what you're saying to its core: you can avoid the need to make callers async if you simply make everything async. In essence, that's the choice Go made. It's certainly simpler for the programmer. It probably makes optimization trickier, and it probably makes efficient parallelism harder (since real threads are completely abstracted away, the VM needs to understand when to start real threads, and when to use promises). For a language like javascript, it sounds like these tradeoffs are certainly worth it.
- kevingadd 12y ago
  async/await is not based on generators. It's a compile-time transform that hoists parts of your function into independently scheduled asynchronous tasks & task callbacks. So it's essentially automatic CPS + promises. That's why functions are tagged as 'async' or not-async in C#; if they are 'async' they produce a promise instead of a value. On a related note, part of C#'s async/await infrastructure is a scheduling system so that callbacks can be configured to run on a specific thread - i.e. you can kick off async work on the UI thread and the callbacks will run there, instead of on the threadpool thread that completed the work.
interroboom 12y ago
there are third party libraries (bluebird, co, Q, etc) that use generators to yield promises (or lightweight alternatives such as 'thunks'), and then a helper function that handles waiting for those promises/thunks to return and then resuming the generator. annoying that its not baked into ES6, but it means async code can be basically written like sync code (including typical error handling)

munificent 12y ago

> My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.

saurik 12y ago
This is only true if you are building the implementation of async/await as a compilation hack (maybe a "transpiler", as people now like to say) rather than as a feature of the virtual machine. You don't need "threads" to implement this, you just need the ability to work with multiple stacks and then have use the techniques from coroutines. (Some people call this "green threads", but that's not the kind of "threads" you would refer to when saying C# has threads.) I imagine the reason they avoided doing this was to not require browser vendors to make half their browser internals safe for usage in reasonable coroutines ;P. I can also see them having wanted to guarantee that the feature could be implemented using a transpiler rather than requiring it to be a native feature of the browser, and generators being explicitly marked at both the declaration and call sites (or async await with the limitations you mention) have that property by allowing a continuation passing transform to be applied to the generator's code. (Which could be applied to all code, of course, but not native browser code. edit: Well, you could so that as well, but it would violate other assumptions about how the code is supposed to work, and isn't something anyone has infrastructure to accomplish ;P.)
- emn13 12y ago
  To condense what you're saying to its core: you can avoid the need to make callers async if you simply make everything async. In essence, that's the choice Go made. It's certainly simpler for the programmer. It probably makes optimization trickier, and it probably makes efficient parallelism harder (since real threads are completely abstracted away, the VM needs to understand when to start real threads, and when to use promises). For a language like javascript, it sounds like these tradeoffs are certainly worth it.
kevingadd 12y ago
async/await is not based on generators. It's a compile-time transform that hoists parts of your function into independently scheduled asynchronous tasks & task callbacks. So it's essentially automatic CPS + promises. That's why functions are tagged as 'async' or not-async in C#; if they are 'async' they produce a promise instead of a value. On a related note, part of C#'s async/await infrastructure is a scheduling system so that callbacks can be configured to run on a specific thread - i.e. you can kick off async work on the UI thread and the callbacks will run there, instead of on the threadpool thread that completed the work.

interroboom 12y ago

there are third party libraries (bluebird, co, Q, etc) that use generators to yield promises (or lightweight alternatives such as 'thunks'), and then a helper function that handles waiting for those promises/thunks to return and then resuming the generator. annoying that its not baked into ES6, but it means async code can be basically written like sync code (including typical error handling)