W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

From: Mark S. Miller <erights@google.com>
Date: Wed, 24 Apr 2013 08:36:54 -0700
Message-ID: <CABHxS9gYAz-R=y-gbFACaqeGEJh6mpCK0LKEXiAy9KBSeCmu9Q@mail.gmail.com>
To: Till Schneidereit <tschneidereit@gmail.com>
Cc: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, TC39 <e-TC39@ecma-international.org>
The Roadmap will be on the agenda for the upcoming TC39 May meeting. Many
of us want macros eventually, the ES6 module system gives us the stage
separation necessary for clean macros, and I don't recall any objections to
eventually including macros if they are clean enough. But macros are a big
hard design space, and the most explored form of cleanliness, known as
"hygiene", is insufficient by itself. I cannot imagine discussions of
macros converging fast enough for ES7, given the urgency for shipping ES7
quickly. I do think it makes sense to add macros to the agenda for ES8.

On Wed, Apr 24, 2013 at 7:44 AM, Till Schneidereit

> Is there any chance at all of macros  la sweet.js will be on the agenda
> for ES7 (or 8)?
> I would very much like for that to happen to enable even more, and more
> light-weight, experimentation with and cow-path building for the syntactic
> language surface.
> On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller <erights@google.com>wrote:
>> (Thanks to Rick Waldron and Brendan Eich for encouragement towards
>> posting this)
>> As we see on es-discuss, the pressure towards standardizing soon various
>> features currently absent from ES6 is increasing. Rather than stretch ES6,
>> I think we should work towards completing ES6 asap, and then proceed to
>> ship an ES7 that is both more modest and out earlier than current
>> expectations. I think the focus of ES7 should be parallelism, concurrency,
>> asynchrony, and preparation for distribution. Call this the "concurrency
>> theme". This involves at least
>>   * Communicating Event Loop concurrency model,
>>       - with the two-priority event loop already required by both browser
>> and server.
>>   * Object.observe
>>   * Distribution compatible promises (at least Promises/A+)
>>   * Module Loaders
>>   * Weak References
>> I hesitate to put Module Loaders on the above list rather than leaving
>> them in ES6; but it would allow their semantics to rest on event loops and
>> their API to rest on promises. If we can get ES7 out quickly, this need not
>> be as painful as it might seem, and would help us ship ES6 faster.
>> Elements of the concurrency theme that may be in ES7 or may be postponed
>> to ES8:
>>   * RiverTrail
>>   * The Vat model
>>   * The semantics of inter-vat communications
>>       - including a principled alternative of structured clone
>>       - The emphasis being remote object messages, with postMessage
>>           and such being only one of many transports.
>>   * The promise hooks needed to extend promises securely over the network
>>       - See makeFar and makeRemote at
>> https://code.google.com/p/es-lab/source/browse/trunk/src/ses/makeQ.js#410
>>   * Event streams
>> How much of the latter we bite off in ES7 and how much we delay till ES8
>> will determine how quickly we can ship ES7. But however they split between
>> ES7 and ES8, I think these should be the next things on our plate after ES6.
>> Some things that I think should clearly wait till ES8:
>>   * SES
>>   * Distributed persistence
>>   * The actual distributed cryptographic protocol for doing distributed
>> secure persistent object communications.
>> Some of these should perhaps be on separate tracks within TC39, much as
>> i18n is already on a separate track.
>> Some non-concurrency issues that will nevertheless be pressing in the ES7
>> timeframe:
>>   * Completing the class design
>>       - at least high integrity and private state
>>   * Quasi-parsers for JS, HTML, CSS
>>   * Pinning down the full semantics of inter-realm interaction within a
>> Vat, e.g.,
>>       - multiple same-domain iframes
>>       - loader-created fresh frames
>>   * Possibly lexically nested modules
>> Although I'm posting this on three lists, discussion should proceed only
>> on es-discuss.
>> Thoughts?
>> --
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss

Received on Wednesday, 24 April 2013 15:37:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC