await on synchronous functions

[Ben Newman]

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!
On Fri, Jul 17, 2015 at 12:50 PM Mark Volkmann <r.mark.volkmann at gmail.com>
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 <benjamin at cs.stanford.edu>
> 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 <toshok at gmail.com> 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 <benjamin at cs.stanford.edu>
>>> 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 <
>>>> andrea.giammarchi at gmail.com> 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 <tomvc.be at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <
>>>>>> andrea.giammarchi at gmail.com>:
>>>>>>
>>>>>>> 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 <zenparsing at gmail.com>
>>>>>>> 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
>>>>>>>> es-discuss at mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss at mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/2336849e/attachment-0001.html>