More flexibility in the ECMAScript part? (was: Re: Futures

David Bruant bruant.d at
Wed Apr 17 14:25:20 PDT 2013

Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
> On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
>> ...
>> Although promises were planned for ES7, they weren't part of any 
>> formal spec. As far as I know, no recent TC39 meetings even mentioned 
>> the concurrency strawman [2].
> i don't think the "mention" observation is totally correct.  More 
> generally, it is the actual TC39 participants who set the agenda for 
> meetings and who build the necessary consensus to advance proposals. 
>  That is how the ES7 observe proposal has advanced as rapidly as it 
> has.  It is up to champions of specific proposal (such as Alex or 
> Mark, in this case, but it could be others) to add appropriate agenda 
> items and to move the process forward.
But that didn't happen. Instead, Alex Russel gathered a couple of 
people, started with a minimal proposal privately then opened it up to 
public feedback, then it entered the WHATWG DOM spec (people have mixed 
feelings about that), this news has been so important it was shared to a 
couple of W3C mailing lists I follow and there seems to be plan to 
incorporate promises to other W3C specs.

Object.observe has moved quite fast, but still can't be consumed by 
other specs as far as I can tell (there might also be an outreach issue 
which is a different one)

>> No formally accepted and agreed upon spec makes ES7 promises and the 
>> concurrency strawman virtually inexistent. The current largely 
>> informal agreement on the concurrency strawman doesn't solve the 
>> current problem of the web platform using promises/futures.
>> I believe the problem lies in that ECMAScript has a monolitic spec 
>> snapshot model. This model doesn't allow the flexibility needed by 
>> WebIDL and the web platform which are an important consumer of the 
>> spec. I believe this is why the WHATWG was chosen to host the Future 
>> spec work [4].
> TC39 does not exclusively do monolithic specs. See for example 
> Ecma-402, the ECMAScript initialization API [5] which is a modular 
> addition to Ecma=262.  It is also a good example of domain experts 
> working within the context of TC39 to focus attention on a specific 
> feature area.
True. Can you provide a list of the next upcoming ECMA-xxx, please?

> However, there is a very good reason that the ECMAScript Language 
> specification is a monolithic spec.  Language design is different from 
> library design. (...)
The topic at hand is promises which is a library. I entirely agree with 
the rest of what you said about language design. I'm perfectly fine with 
the JS "virtual machine+syntax" being spec'ed as monolithic and agree it 
should for the reasons you cited.

> There is stuff in Ecma-262, particularly as ES6 emerges, that are 
> basically library features and there has been casual conversations 
> within TC39 about the desirability and practicality of of having 
> separate standards for  some library components.  Ecma-402 is an 
> example of this.  However, some care needs to be exercised here 
> because sometimes library based features are actually cross-cutting 
> language semantic extensions that are just masquerading as a library.
I understand. Has the Future [1] proposal been reviewed with this needed 
care? If not, can this be added to the agenda for the next meeting? (so 
asks the non-TC39 guy :-p) It feels important.

>> Assuming this is the agree cause, would it make sense for the 
>> ECMAScript spec model to change to fit the flexibility needs of 
>> WebIDL and the web platform?
>> I'm also going to ask a pretty violent question, but: does it still 
>> need to be spec'ed by ECMA? The only argument I've heard in favor of 
>> staying at ECMA is that some people still find ISO standardization 
>> and Word/PDF important. Can this be re-assessed? Especially given the 
>> recent promise/future mess?
> Language design is what it is, and to responsibly extend ECMAScript 
> you need to have experienced language designers engaged. I think 
> organizational venues and process has very little to do with the 
> actual pragmatics of how you design extensions for a language as 
> prominent as JavaScript.
I'm glad we agree on this point :-)



More information about the es-discuss mailing list