<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 17, 2015 at 12:50 PM, Mark Volkmann <span dir="ltr"><<a href="mailto:r.mark.volkmann@gmail.com" target="_blank">r.mark.volkmann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Going back to my original question, suppose I write this:<span class=""><div><br></div><div><div style="font-size:12.8px">for (let fn of myFunctions) {</div><div style="font-size:12.8px">  let result = await fn();</div><div style="font-size:12.8px">  // Do something with result.</div><div style="font-size:12.8px">}</div></div><div style="font-size:12.8px"><br></div></span><div style="font-size:12.8px">If all the functions happen to be synchronous and take a while to complete, am I blocking the event loop?</div><div style="font-size:12.8px">I think what I'd like to happen is for each call to happen in the next pass through the event loop.</div></div></blockquote><div><br></div><div>Each iteration would queue a job that includes the continuation of the await, which includes all future iterations. So all jobs queued between when one iteration is schedules vs when it executes, scheduling the next iteration, would be interleaved between the iterations. So IIUC this already does exactly what you want.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Jul 17, 2015 at 2:44 PM, Ben Newman <span dir="ltr"><<a href="mailto:benjamin@cs.stanford.edu" target="_blank">benjamin@cs.stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br><br>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.<div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 17, 2015 at 12:36 PM Chris Toshok <<a href="mailto:toshok@gmail.com" target="_blank">toshok@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think we're confusing two different cases here:<div><br></div><div>1) usage of `await` in the body of a function that is not itself marked as `async`</div><div>2) usage of `await f()` where `f` is not marked as `async`.</div><div><br></div><div>1 is easy to mark as an early error (and should be imo).  2, not so much (and is what Mark was asking?)</div></div><div dir="ltr"><div><br></div><div>-c</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman <span dir="ltr"><<a href="mailto:benjamin@cs.stanford.edu" target="_blank">benjamin@cs.stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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!<br><br>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!).<br><br>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.<br><br>Here are some slides from a talk I gave earlier this year about the benefits and pitfalls of coroutines, in case you're interested: <a href="http://benjamn.github.io/goto2015-talk" target="_blank">http://benjamn.github.io/goto2015-talk</a></div><div><div><div class="gmail_quote"><div dir="ltr">On Fri, Jul 17, 2015 at 11:35 AM Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> <span style="font-size:12.8000001907349px">Think about a large program where you refactor a single async function to no longer be async</span><div><span style="font-size:12.8000001907349px"><br></span></div></div><div dir="ltr"><div><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Apologies if I can't see your point but we've been talking about "Promise must Promise" so much this answer was absolutely unexpected.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Thanks for any sort of clarification</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com" target="_blank">tomvc.be@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span>:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If I might, if there's one thing that has never particularly shone in JS, that is consistency.<div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>regards,</div><div>Tom</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Just my quick thoughts</div><div><br></div><div>Best Regards</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <span dir="ltr"><<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<br clear="all"></div></blockquote><div><br></div></span><div>More generally, the question is: what should await do for non-promises?</div><div><br></div><div>    await 1;</div><div><br></div><div>Should it force a job to be queued?</div></div></div>
<br></div></div>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="arial, helvetica, sans-serif">R. Mark Volkmann</font></div><div><span style="font-size:12.8000001907349px"><font face="arial, helvetica, sans-serif">Object Computing, Inc.</font></span></div></div></div></div></div></div></div></div>
</span></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">    Cheers,<br>    --MarkM</div>
</div></div>