On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman <[email protected]> wrote:
> If we stick with the rule that await is only regarded as a keyword if it > appears in the body of an async function, then await x without async is > simply a syntax error, and we can avoid having to answer this question! > Two more possible contexts: * We've talked about allowing await at the top level of modules, I think so that the await continuation could proceed after the synchronous part of the load. I am unclear on the details and cannot reconstruct a sensible story from memory. * Jafar and I will be making a proposal for allowing await within function* generator functions. No need to debate this until we make the proposal, but it does not alter what await would do inside an async function. > > That said, perhaps a more natural way of handling wayward await > expressions is to treat them as referring to the closest enclosing async > function on the call stack (not necessarily the immediate enclosing > function), throwing an exception if there is no async function on the stack. > This would have the same hazards as deep generators: Intermediate functions on the call stack could be postponed till later turns/jobs without their knowledge, causing violations of their assumptions. The event-loop model makes strong guarantees about possible interleaving. We defined generators and async functions as shallow to preserve those guarantees. > Then any await expression would delay the resolution of the Promise > returned by whatever async function is currently executing. The > same-function-body syntax restriction is a special case of that more > general model (and notably easier to implement by transpiling to > generators!). > > Generalizing async/await in this way turns out to be equivalent to > introducing coroutines into the language, > Exactly! Same think for deep generators. That's why we must not do either. > and while I would love to see that happen one day (it would greatly > simplify writing parallel forEach loops, for example), it would require > substantial changes to the execution model of the language. > > Here are some slides from a talk I gave earlier this year about the > benefits and pitfalls of coroutines, in case you're interested: > http://benjamn.github.io/goto2015-talk > I'll take a look. But I've already looked at fibers themselves and rejected them on this basis. > On Fri, Jul 17, 2015 at 11:35 AM Andrea Giammarchi < > [email protected]> wrote: > >> > Think about a large program where you refactor a single async function >> to no longer be async >> >> did that ever happened in the history of logic? I am actually curious to >> understand a single valid case where that would be a solution to any >> problem. >> >> Apologies if I can't see your point but we've been talking about "Promise >> must Promise" so much this answer was absolutely unexpected. >> >> Thanks for any sort of clarification >> >> On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem <[email protected]> >> wrote: >> >>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi < >>> [email protected]>: >>> >>>> If I might, if there's one thing that has never particularly shone in >>>> JS, that is consistency. >>>> >>>> I see only two possibilities here: 1) it throws with non Promises 2) it >>>> "Promisify" anything that's not a Promise as if it was a >>>> `Promise.resolve(1)` ... but since there's too much magic in the second >>>> point, I'd rather stick with the first one. >>>> >>> >>> I would be highly in favor of (2). Think about a large program where you >>> refactor a single async function to no longer be async. Then I see no >>> reason why I should be forced to refactor all of its callers to remove the >>> await keyword. Going from sync to async requires refactoring because you're >>> introducing new potential interleaving hazards, but any code that is >>> already prepared to work with async functions (or promises in general) >>> should work equally fine on immediately resolved promises. >>> >>> regards, >>> Tom >>> >>> >>> >>>> >>>> Just my quick thoughts >>>> >>>> Best Regards >>>> >>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <[email protected]> >>>> wrote: >>>> >>>>> I know the spec for this isn't finalized, but what is the current >>>>>> direction for the behaviour when await is used on a function that is not >>>>>> marked async and doesn't return a Promise? Should it run immediately or >>>>>> wait for the next turn of the event loop? >>>>>> >>>>> >>>>> More generally, the question is: what should await do for non-promises? >>>>> >>>>> await 1; >>>>> >>>>> Should it force a job to be queued? >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
