await on synchronous functions

Fri Jul 17 21:55:53 UTC 2015

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!
>

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 <
> 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
>
>

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/e498db90/attachment.html>