await on synchronous functions

Tue Jul 21 12:52:38 UTC 2015

Just a few points to be careful about:

Several people have been trying to assert in threads that await can be used
to solve synchronous problems; but just like Dean stated, you need to turn
the event loop which makes it problematic for things like
https://github.com/whatwg/loader/issues/54 need to be sure we do not get
confused.

I want to make sure that any proposal does not squash the idea of
Compositional Functions (
https://github.com/jhusain/compositional-functions/ ). For various reasons
we do not use async/await with promises currently and use the same
semantics as compositional promises due to resource management.

On Mon, Jul 20, 2015 at 10:57 AM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
> On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> Meaning putting a Promise in a chain of promises is a point of no return
>> so I've never seen/heard/imagined a case where you have a promise and
>> suddenly you refactor that to be synchronous.
>>
>
>
> This is a great point, and I think makes a good argument against the
> refactoring use case. But there are other plenty of other interesting use
> cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics
> would allow you to write generic sync/async handlers, which comes up all
> over the place.
>
> This approach neatly cleans up some of the inconsistencies around handling
> sync throws vs. rejections vs. *zalgo* throws (usually promise-returning
> functions which throw before returning a promise). A try/catch around some
> `await` will handle all three cases the same, almost -- there's one small
> catch (w/ apologies for the bad pun)...
>
> IIUC the behavior of `Promise.resolve` alone are insufficient to get
> identical semantics between sync and async calls -- you'd need to spin the
> event loop before rethrowing a sync exception, akin to the behavior of
> bluebird's `Promise.try`. A minor detail, but punting on this would force
> users into wrapping every call with something like `Promise.try`, which
> seems like a shame. ISTM these `try` semantics, rather than
> `Promise.resolve`, are more natural as the foundation for `await`.
>
>
> The specific "Promise gonna  Promise" was actually mentioning another
>> thread about cancelability and the fact "Promises are Promises and  should
>> just Promise" :-)
>>
>> Sorry for the confusion
>>
>> On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>> Hi Andrea, what do you mean by "Promise must Promise"? I've never seen
>>> this phrase before.
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150721/671bfc24/attachment-0001.html>