On Apr 17, 2013, at 2:25 PM, David Bruant wrote: > 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.
You have to ask Alex about that. We all, as individual (subject to constraints our employers might impose), can create designs, circulate them, find supporters, promote their use, etc. But that is just personal action. However, when a standards setting organization (SSO) agrees to undertake the development of a standard, that is a very different affair and formal rules start to apply. For example, there may be rules on dependencies. Such as the rule that an Ecma (or ISO) standard is not allowed to normatively reference things that aren't also normative standards from a recognized SSO. Differed organizations also have different chartered areas of responsibilities. One of the concerns I heard raised here is that Futures may more appropriately fall into TC39 areas of responsibility. Often when SSO find they have some overlap of interest they will find a way to jointly develop a standard. > > 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) Object.observe isn't part of a finished standard yet. There is a fairly detailed proposal [2] (but not an official specification draft) that has been "accepted" by TC39 as the basis for a future standardized specification. Some people are working on browser implementation based upon the proposal. It is expect that the ultimate specification may vary somewhat from the proposal based upon feedback from those implementations. Whether or not other specs chose to take dependencies upon Object.observe probably depends upon the rules they operate under plus their judgement of associated risks. ... >> >> 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? Work is already underway on the 2nd edition of Ecma-402, the Internationalization APIs. That (other than ES6) is the only formal standard in the current pipeline but there are other exploratory projects (see [3]) that are likely to either become part of the ES7 effort or a separate spec. > >> 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. Yes, but it is an library that extends the sequential execution model of ES. That's a significant language level change to the ES specification. We are already scrambling to a certain degree in the ES6 spec. to make it align with the browser-reality eventing model. 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. > >> 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. no and see my first response above. It can be as important as the TC39 members choose to make it. TC39's agenda is largely driven by feature champions. > ... > David > > [1] http://dom.spec.whatwg.org/#futures >> ... [2] http://wiki.ecmascript.org/doku.php?id=harmony:observe [3] http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
