No more modes?
Mark S. Miller
erights at google.com
Mon Oct 18 06:54:24 PDT 2010
On Mon, Oct 18, 2010 at 6:47 AM, Dmitry A. Soshnikov <
dmitry.soshnikov at gmail.com> wrote:
> P.S.: also it seems I missed something, can someone clarify -- are
> `let` and `const` are removed from Harmony proposals since they shouldn't
> appear in ES5-strict (in the recommendations for implementations as I see)
> and since ES6 will be built on ES-strict?
No. We recommend that ES5/strict implementations reject 'let' and 'const'
for now, so that there's no established divergent semantics by the time we
codify their harmony semantics. Once there harmony semantics are adequately
settled, proceeding to implement them in ES5/strict would be fine. Likewise
with nested named function declarations.
> P.S. @MarkMiller: just a small (off-topic) clarification: do new
> `Object.getPropertyDescriptor` and `Object.getPropertyNames` consider in
> _addition_ prototype chain or start lookup from the first object in the
> prototype chain? Because I need to implement JS shim for these two things
> and seems I understood not correctly e.g. `Object.getPropertyDescriptor`which doesn't consider own properties, but starts its analysis from the
> first object in the prototype chain.
> On 18.10.2010 14:17, Dmitry A. Soshnikov wrote:
> (At last I've read this thread; I'll answer not for this exact letter, but
> in general).
> So, there are two backward compats issues:
> 1. Running an old code (with possible naming conflicts such as `let`,
> `const`, etc) in a new (ES6) engines; thus, there is no new syntax involved;
> 2. Running new code in the old engines (the issue with a new syntax).
> For the first sub-problem a `use harmony;` directive can be enough. This
> also will work in non-browser host environments (such as CommonJS /
> However, in a view of exactly a pragma directive (i.e. not as a "use
> strict"; string literal) it will cause the second issue, i.e. a syntax error
> in all browsers (just right at the first line because they won't be able to
> parse this pragma). But, being in the "use harmony"; view (as a string
> literal) also won't solve the issue. Because old browsers even if won't fail
> on the first line, will do it later when find a new syntax (because the code
> will be ran anyway).
> So for exactly old browsers the approach with:
> <script type="harmony">
> seems good (if not the only possible) since this block won't be even
> And for server-side JS -- there the approach a little different: the same
> the new code in old engines won't work -- syntax errors (and seems there are
> no other obvious ways to prevent it besides checking the MAX_ES_VERSION and
> require(...) dynamically needed code). But more likely, on the server side
> it's cheaper and easier to update the engine which support the new syntax
> (thus, even "use harmony;" isn't needed -- so <script type="harmony"> seems
> wins -- because the issue mostly touches exactly browser host environments).
> P.S.: and experiments with <script-if-else> may be leaved for more needed
> On 15.10.2010 21:30, Brendan Eich wrote:
> On Oct 14, 2010, at 3:47 PM, Brendan Eich wrote:
> Seriously, we don't want a version lattice with bad combinatorics. We've
> been over this in TC39 meetings and there are records on the wiki. The
> prominent memento is 3(I) at:
> Prior to Means 3(I), there is Goal 4 (
> Keep versioning as simple and linear as possible.
> We don't have concrete plans for a "use strict" in Harmony to opt into a
> "stricter than ES5 strict" mode. The "no more modes" plea is good as far as
> it goes (just not absolute), so I hope we do not add any such
> Harmony-strict-mode. We're really trying not to make an N-dimensional
> version/mode/pragma lattice.
> But, again, ES5 makes incompatible (slight) changes to the de-facto
> standard JS ("ES3R") language, and ES5 strict is indeed a mode. New syntax
> is coming, but we will build it on ES5 strict under some kind of opt-in.
> The minimum opt-in mechanism, we think, is specified by RFC4329: <script
> type="application/ecmascript;version=6">. This works in IE9, in the sense
> that the script tag content is not processed (thanks to Jeff Walden for
> testing). Testing in older and other browsers welcome,with and without the
> ;version= parameter.
> Markup-based version selection, to allow inline, out of line (src=) with
> prefetching, and downrev-browser fallback without "autoconf-style"
> generation of script elements, seems worth considering.
> - Will we have to add yet another mode each time we add syntax? After
> enough iterations this becomes unsustainable.
> Languages don't grow indefinitely but JS syntax (and semantics) are gappy
> enough there could be another edition that comes after the first Harmony
> That was a bit too neutral-sounding.
> I want to add that my strong desire is to avoid adding syntax after the
> "Harmony edition" (let's hope it is ES6, but we have been burned picking
> numbers prematurely in the past, and there's no need yet to pick a number).
> I'm simply skeptical about our ability to predict the future or enforce a
> bad prediction.
> Modules should give everyone writing libraries (least of all TC39)
> name-conflict-free upgrade paths, along with lexical scope all the way up
> (no global object). If we ever get to the promised land of macros, we'll
> need modules (and a lot else; macros are very much a dark horse, or just a
> gleam in my eye).
> So modules are important. Proxies too. So are
> let/const/function-in-block. Some less critical but worthwhile conveniences
> matter too, enough that they're in the harmony section of the wiki.
> If you ask me, the list outlined in the last paragraph is enough for
> "Harmony". I'm not sure we need classes or traits in the language; more work
> (under way) is needed to find out.
> My two cents, and as usual I reserve the right to change my mind, or
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss