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. > 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. However, there is a very good reason that the ECMAScript Language specification is a monolithic spec. Language design is different from library design. Programming language designs are notorious for the cross-cutting syntactic and semantic issues that arise when new langue level features are added. It would be irresponsible to try to introduce a new features without considering how it interacts with all other features of the language. It also, isn't best practice to to only sequentially design in new features as this may lead to decision decisions that are hostile to other feature requests that are in the pipeline. 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. > > 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. > Other parts of the platform (thinking of DOM, DOM Events, XHR, forgetting > about HTML5 specifically) have survived to the living standard model with > success. The rumor on the street is that their latest editor draft of a lot > of W3C is in HTML format; that would encourage a tighter feedback loop. > Node.js is becoming more and more popular and I don't believe ECMAScript 5.1 > being an ISO standard is that important for the people interested in Node.js > (probably even the business-focused ones). > > To a large extent the flexibility I'm asking for is already in place between > TC39 and implementors (features are prototyped before being fully spec'ed). > It just needs to be extended to another important consumer of the spec that > is WebIDL. I would express this as, the web platform is the most important host environment for ECMAScript (that's how TC39 thinks of it). It is important that the architects of the web platform communicate their requirements, priorities, and timeframes to TC39 as the maintainers of ECMAScript and that TC39 is responsive to them. There really are no barriers to this, after all, many of us work for organizations that actively participate in both W3C and TC39 activities. Regarding WebIDL, while it has improved it is still a terrible fit to ECMAScript and attempts to extend the ECMAScript language semantics via WebIDL is a really bad idea as it circumvents the language design best practices mentioned above. WebIDL is not a good rallying point for better W3C/TC39 convergence. Allen > > David > > [1] https://github.com/slightlyoff/DOMFuture > [2] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency > [3] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026188.html > [4] http://dom.spec.whatwg.org/#futures [5] http://www.ecma-international.org/ecma-402/1.0/ > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
