On Fri, Jul 17, 2015 at 12:57 PM, Ben Newman <[email protected]> wrote:
> Yep, all current implementations that I know of (Traceur, > Babel/Regenerator, various other generator-based approaches) do what you > want, because Promise.resolve(fn()).then(result => ...) always runs the > callback a future turn of the event loop. > > Please note I might not be using the term "turn" precisely here > (microtask?); my point is just that your example would not be blocking the > event loop, and that's a good thing! "task" and "microtask" are browser concepts, not JS concepts. The JS concept is indeed what E calls a "turn", but the official EcmaScript standards language for turn is "job". Please let's stick with "job". > > On Fri, Jul 17, 2015 at 12:50 PM Mark Volkmann <[email protected]> > wrote: > >> Going back to my original question, suppose I write this: >> >> for (let fn of myFunctions) { >> let result = await fn(); >> // Do something with result. >> } >> >> If all the functions happen to be synchronous and take a while to >> complete, am I blocking the event loop? >> I think what I'd like to happen is for each call to happen in the next >> pass through the event loop. >> >> On Fri, Jul 17, 2015 at 2:44 PM, Ben Newman <[email protected]> >> wrote: >> >>> Having addressed (1) earlier, perhaps by mistake, my thought on (2) is >>> that you probably want await f() to work the same way if f() just happens >>> to return a Promise, as when f is actually async, but there is no way to >>> know, in general, if some arbitrary function will or will not return a >>> Promise, so await should treat all arguments in the same way: by calling >>> Promise.resolve. >>> >>> It's an open question whether a sufficiently smart runtime could >>> optimize cases when the argument is not a Promise, or when the Promise is >>> already resolved, but it would have to do so under the constraint of not >>> revealing that optimization to the user. >>> >>> On Fri, Jul 17, 2015 at 12:36 PM Chris Toshok <[email protected]> wrote: >>> >>>> I think we're confusing two different cases here: >>>> >>>> 1) usage of `await` in the body of a function that is not itself marked >>>> as `async` >>>> 2) usage of `await f()` where `f` is not marked as `async`. >>>> >>>> 1 is easy to mark as an early error (and should be imo). 2, not so >>>> much (and is what Mark was asking?) >>>> >>>> -c >>>> >>>> >>>> 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! >>>>> >>>>> 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. 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, 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 >>>>> 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 >>>>> >>>>> >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> > > _______________________________________________ > 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
