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

Till Schneidereit tschneidereit at gmail.com
Wed Apr 24 08:39:41 PDT 2013


Thanks, that makes a lot of sense to me.


On Wed, Apr 24, 2013 at 4:36 PM, Mark S. Miller <erights at google.com> wrote:

> 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 <
> tschneidereit at gmail.com> wrote:
>
>> 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 at 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 at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130424/1d3069e7/attachment.html>


More information about the es-discuss mailing list