Are Promises and Microtasks introduced into ES6?

Yusuke SUZUKI yusukesuzuki at chromium.org
Fri Oct 4 11:37:51 PDT 2013


On Fri, Oct 4, 2013 at 3:39 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Yusuke SUZUKI wrote:
>
>> Make sense. So microtasks won't be introduced yet, but Promises and
>> asynchronous execution semantics (enough for Promises) are introduced into
>> ES6. Is it correct?
>>
>
> And enough for modules.
>
> And really, as dherman points out, the event loop and shared state
> concurrency have haunted ECMA-262 like Banquo's ghost, forever.
>
> But yes, for ES6 we are going to do "as little as possible". (I hope this
> doesn't end as it did in the movie.)


I've got it. It's very interesting progress :)

On Fri, Oct 4, 2013 at 3:46 AM, Mark S. Miller <erights at google.com> wrote:

> Yes. The only immediate correctness constraint needed in ES6 and the
> immediate DOM timeframe is the "empty stack" requirement
>
> Stated at <
> https://github.com/domenic/promises-unwrapping#coercethenablethenable-then>
> as
> "4. Assert: the execution context stack is empty."
>
> Stated at <https://github.com/promises-aplus/promises-spec#the-then-method>
> as
> "4. onFulfilled or onRejected must not be called until the execution
> context stack contains only platform code. [3.1]."
>

Thanks. I understood the meaning of these statements.


On Fri, Oct 4, 2013 at 3:46 AM, Mark S. Miller <erights at google.com> wrote:

> Yes. The only immediate correctness constraint needed in ES6 and the
> immediate DOM timeframe is the "empty stack" requirement
>
> Stated at <
> https://github.com/domenic/promises-unwrapping#coercethenablethenable-then>
> as
> "4. Assert: the execution context stack is empty."
>
> Stated at <https://github.com/promises-aplus/promises-spec#the-then-method>
> as
> "4. onFulfilled or onRejected must not be called until the execution
> context stack contains only platform code. [3.1]."
>
> citing <https://github.com/promises-aplus/promises-spec#notes> stating:
> '1. Here "platform code" means engine, environment, and promise
> implementation code. In practice, this requirement ensures that onFulfilled
> and onRejected execute asynchronously, after the event loop turn in which
> then is called, and with a fresh stack. This can be implemented with either
> a "macro-task" mechanism such as setTimeout or setImmediate, or with a
> "micro-task" mechanism such as MutationObserver or process.nextTick. Since
> the promise implementation is considered platform code, it may itself
> contain a task-scheduling queue or "trampoline" in which the handlers are
> called.'
>
> Some of the underlying issues this addresses are explained at the <
> https://github.com/promises-aplus/promises-spec/issues/139> thread and
> the previous issue threads it cites.
>
>
>
>
> On Thu, Oct 3, 2013 at 10:41 AM, Yusuke SUZUKI <yusukesuzuki at chromium.org>wrote:
>
>> Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <slightlyoff at google.com>
>>  wrote:
>>
>>> Only that a suitable hook is needed that embedders can implement.
>>> Luckily that's simple WRT existing semantics (we are oblivious to future
>>> turns at the language level) and doesn't demand that we import the event
>>> loop itself into the language. The only requirement is that promises are
>>> async WRT the calling code. Delivery at the end of the current turn is
>>> allowed. Object.observe will require that we define an order, but until
>>> then, hand waving is sufficient.
>>>
>>
>> Make sense. So microtasks won't be introduced yet, but Promises and
>> asynchronous execution semantics (enough for Promises) are introduced into
>> ES6. Is it correct?
>>
>> _______________________________________________
>> 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/20131005/2a96aba5/attachment.html>


More information about the es-discuss mailing list