More flexibility in the ECMAScript part?

David Bruant bruant.d at
Thu Apr 18 00:31:57 PDT 2013

Le 18/04/2013 05:07, Tab Atkins Jr. a écrit :
> On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
> <allen at> wrote:
>> A a rule of thumb, if a library does something that can not be expressed in
>> the its base language there is a good chance it is extending "the virtual
>> machine" of the language and it should at least be reviewed from that
>> perspective and iframe semantics.  These are both examples of browser design
>> choices that have deep semantics impact upon the language.
> Note that Futures are entirely expressible in today's JS semantics.
Allen was concerned about the "ECMAScript" definition of what you're 
loosely calling "JS" while it seems you're referring to "web platform 
enhanced JavaScript"
Specifically, the current semantics uses "queue a task" which interacts 
with the event loop which is part of the web platform, but not ECMAScript.

I've read intention to move the event loop from HTML Living Standard to 
ECMAScript 7, but we're not there yet and that work is necessary before 
adding promises to ECMAScript.


More information about the es-discuss mailing list