On Fri, Oct 4, 2013 at 3:39 AM, Brendan Eich <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > <[email protected]>wrote: > >> Thu, Oct 3, 2013 at 11:43 PM, Alex Russell <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
