- From: Till Schneidereit <tschneidereit@gmail.com>
- Date: Wed, 24 Apr 2013 16:39:41 +0100
- To: "Mark S. Miller" <erights@google.com>
- Cc: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, TC39 <e-TC39@ecma-international.org>
- Message-ID: <CAD0sBY4pJJRBkVuUBPpFyE_-yY79dgmXtbLBevyiU6OGkH8rfQ@mail.gmail.com>
Thanks, that makes a lot of sense to me. On Wed, Apr 24, 2013 at 4:36 PM, Mark S. Miller <erights@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@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@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 >>> >>> >> > > > -- > Cheers, > --MarkM >
Received on Wednesday, 24 April 2013 15:40:14 UTC