Are Promises and Microtasks introduced into ES6?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Are Promises and Microtasks introduced into ES6?

Yusuke SUZUKI-2
Hi,

I'm very interested in implementing Promises and integrating it to ECMAScript engine (e.g. V8, SpiderMonkey, JSC)

Last night, I saw the meeting notes of Sep TC39 meetings carefully and I was very surprised that it is said that Promises will be introduced into ES6.
It refers the microtasks and the event loop. But I can't find details of the event loop consensus. Is there any consensus about event loop abstraction in ES6?

Thanks,
Yusuke Suzuki

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are Promises and Microtasks introduced into ES6?

Alex Russell-4


On 3 Oct 2013 08:23, "Yusuke SUZUKI" <[hidden email]> wrote:
>
> Hi,
>
> I'm very interested in implementing Promises and integrating it to ECMAScript engine (e.g. V8, SpiderMonkey, JSC)
>
> Last night, I saw the meeting notes of Sep TC39 meetings carefully and I was very surprised that it is said that Promises will be introduced into ES6.
> It refers the microtasks and the event loop. But I can't find details of the event loop consensus. Is there any consensus about event loop abstraction in ES6?

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.

> Thanks,
> Yusuke Suzuki
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are Promises and Microtasks introduced into ES6?

Yusuke SUZUKI-2
Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are Promises and Microtasks introduced into ES6?

Brendan Eich-3
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.)

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are Promises and Microtasks introduced into ES6?

Mark S. Miller-2
In reply to this post by Yusuke SUZUKI-2
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]."

'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 <[hidden email]> wrote:
Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are Promises and Microtasks introduced into ES6?

Yusuke SUZUKI-2
On Fri, Oct 4, 2013 at 3:39 AM, Brendan Eich <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]."

'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 <[hidden email]> wrote:
Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss