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 :-)
David
[1] http://dom.spec.whatwg.org/#futures
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
