Could not get the example deferred function to work with traceur from the wiki page to see what it generates. https://github.com/google/traceur-compiler/wiki/LanguageFeatures
Been talking off list since this is off topic, but keeps coming up. I ended up following Brendan's advice. I have a sweet.js that works well, but still requires a wrapper. https://gist.github.com/bmeck/5146e40d71bbd57ec9ec Tests seem to pass, yielding promises without awaiting, direct eval (without regenerator), usage in regenerator, etc. My macro does no match the semantics of what is in the wiki, but would be interested in how traceur does function returns from deferred functions / if I can use yield. Unsure on how new syntax features like await should deal w/ multiple operands though, like if await wanted to turn multiple promises into an array. Comma operator takes comma separated list out of the equation. On Mon, Jan 27, 2014 at 3:17 PM, Erik Arvidsson <erik.arvids...@gmail.com>wrote: > > On Jan 27, 2014 2:09 PM, "David Herman" <dher...@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.m...@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@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
