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>

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

> 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

Thanks. I understood the meaning of these statements.