On Sun, Apr 21, 2013 at 12:56 AM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
>
> Finally, I know a lot of people, myself included, are excited about `await` sugar. That is, the plan would be to use generators + promises in ES6 with the awkwardness that entails; once we know what the prevailing patterns are we can eliminate that awkwardness with `await` in ES7. (I've made [a sketch][1] illustrating the idea, but of course the point of waiting is to find something that works, not the first thing I think up.) How this fits in with the concurrency strawman's more ambitious `!` operator is unclear though.

I don't see what the point of `await` is in your gist.  It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler like `Q.async`
or `taskjs.spawn`.  We could add that sugar if we wanted, and not need
to add `await`.

Sam

On Sun, Apr 21, 2013 at 12:56 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> Finally, I know a lot of people, myself included, are excited about `await` sugar. That is, the plan would be to use generators + promises in ES6 with the awkwardness that entails; once we know what the prevailing patterns are we can eliminate that awkwardness with `await` in ES7. (I've made [a sketch][1] illustrating the idea, but of course the point of waiting is to find something that works, not the first thing I think up.) How this fits in with the concurrency strawman's more ambitious `!` operator is unclear though.

I don't see what the point of `await` is in your gist.  It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler like `Q.async`
or `taskjs.spawn`.  We could add that sugar if we wanted, and not need
to add `await`.

Sam