domenic at domenicdenicola.com (2013-11-22T17:58:40.167Z)
Kevin Smith <mailto:zenparsing at gmail.com> November 16, 2013 6:56 AM > Heck, why not just add async functions to the agenda? They are on the further-out agenda for ES7, but Object.observe is ahead, and it is driving the event-loop task/microtask specification, which async functions need too. None of this fits in ES6. In contrast, generator arrows are relatively straightforward and might fit in ES6. No schedule chicken, in either case, but no way do async functions + event loop full spec fit in ES6. > There's: > > - Promises, yay > - A well-establish use-case, which is awkward to implement without (as the original post demonstrates) More awkward without generator arrows, but survivable in any event. > - Strong syntactic precedent with C# Syntax is the last of it. BTW Mark was advocating function!, not async function, so there will be bikeshedding. > - Strong semantic cowpath with TaskJS No. That's not a scheduler + event loop spec, and the scheduler there is not the only one or even the default one people will agree to. > - Strong developer interest That applies to a great many things, and libraries are "go". > - A year to work out any kinks : ) No, you're wrong -- ES6 is all but done by March, in the "fussing over typography", heading toward Ecma CC approval in June and GA approval in December. There is no "year". Any kinks would be set in stone and unchangable in a few months. > By "async function", I mean something like: See above. You've completely ignored interoperable scheduler specification, which depends on event loop spec in full.
> Kevin Smith <mailto:zenparsing at gmail.com> > November 16, 2013 6:56 AM > Heck, why not just add async functions to the agenda? They are on the further-out agenda for ES7, but Object.observe is ahead, and it is driving the event-loop task/microtask specification, which async functions need too. None of this fits in ES6. In contrast, generator arrows are relatively straightforward and might fit in ES6. No schedule chicken, in either case, but no way do async functions + event loop full spec fit in ES6. > There's: > > - Promises, yay > - A well-establish use-case, which is awkward to implement without (as > the original post demonstrates) More awkward without generator arrows, but survivable in any event. > - Strong syntactic precedent with C# Syntax is the last of it. BTW Mark was advocating function!, not async function, so there will be bikeshedding. > - Strong semantic cowpath with TaskJS No. That's not a scheduler + event loop spec, and the scheduler there is not the only one or even the default one people will agree to. > - Strong developer interest That applies to a great many things, and libraries are "go". > - A year to work out any kinks : ) No, you're wrong -- ES6 is all but done by March, in the "fussing over typography", heading toward Ecma CC approval in June and GA approval in December. There is no "year". Any kinks would be set in stone and unchangable in a few months. > > By "async function", I mean something like: > > async function F(p1, p2, ...pN) { > await G(); > } > > which would de-sugar to something like: > > function F(...args) { > return Task.spawn(function(p1, p2, ...pN) { > (yield G()); > }.bind(this, ...args)); > } > > With a [NoNewLine] after the "async" contextual keyword, obviously. > > Low-risk, high-reward? See above. You've completely ignored interoperable scheduler specification, which depends on event loop spec in full. /be