domenic at domenicdenicola.com (2014-01-30T15:51:39.677Z)
On Jan 27, 2014 2:09 PM, "David Herman" <dherman at mozilla.com> wrote:
>
> I'd like to suggest another sense in which you may have gone down a bad path: you're assuming that await is paired with function*, but it could instead be (like C#) paired with its own async-function syntactic form. Let's say for the sake of argument that async is just a keyword that takes a function form:
>
> ```js
> async function sizeOfZombocom() {
> let all = await download("http://zombo.com");
> return all.length;
> }
> ```
This is similar to way we implemented async in Traceur a few years ago
(time flies). A lot of code can be be shared between generators and async
functions but you do not want to implement async using generators.
On Jan 27, 2014 2:09 PM, "David Herman" <dherman at mozilla.com> wrote: > > I'd like to suggest another sense in which you may have gone down a bad path: you're assuming that await is paired with function*, but it could instead be (like C#) paired with its own async-function syntactic form. Let's say for the sake of argument that async is just a keyword that takes a function form: > > async function sizeOfZombocom() { > let all = await download("http://zombo.com"); > return all.length; > } This is similar to way we implemented async in Traceur a few years ago (time flies). A lot of code can be be shared between generators and async functions but you do not want to implement async using generators. > Imagine we were designing this with a macro system like sweet.js. The temptation is for `async` to unhygienically bind `await` to a macro within its body, but Racket has developed a cleaner mechanism for thinking about paired forms like this, which they call "syntax parameters" (kind of a confusingly generic sounding name) [1] [2]. The basic idea is that you bind both `async` and `await` at the same time, so `await` is always bound, even outside of an async function, but the two collaborate so that `async` informs `await` of its syntactic context. So it would look something like this: > > Example 1: > > import { async, await } from "async"; > > await 1; // syntax error: await used outside of async function > > Example 2: > > import { async, await } from "async"; > > function* sizeOfZombocom() { > let all = await download("http://zombo.com"); // syntax error: await used outside of async function > return all.length; > } > > Example 3: > > import { async, await } from "async"; > > async function sizeOfZombocom() { > let all = await download("http://zombo.com"); // great success > return all.length; > } > > This makes your abstraction airtight: `await` is a concept that belongs to `async` functions, not generator functions; generator functions are merely the internal implementation technique. > > Currently, sweet.js doesn't have syntax parameters, but it'd be a good experiment to add them them and try implementing async/await as I've sketched here. > > Dave > > [1] http://www.greghendershott.com/fear-of-macros/Syntax_parameters.html > [2] http://docs.racket-lang.org/reference/stxparam.html > > On Jan 23, 2014, at 2:14 PM, Bradley Meck <bradley.meck at gmail.com> wrote: > > > I was playing around with generators / looking at await for promises and notices a very difficult thing revolving around generators not having a reference to themselves. > > > > See: > > > > https://gist.github.com/bmeck/72a0f4f448f20cf00f8c > > > > I have to end up wrapping the generator function to get a reference to the generator for passing to nested functions. > > > > Is there a reason the execution context is not a generator / there is no reference back to the generator during [[call]]? > > _______________________________________________ > > es-discuss mailing list > > es-discuss at mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140127/12bef4ca/attachment.html>