<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    (At last I've read this thread; I'll answer not for this exact
    letter, but in general).<br>
    <br>
    So, there are two backward compats issues:<br>
    <br>
    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;<br>
    2. Running new code in the old engines (the issue with a new
    syntax).<br>
    <br>
    For the first sub-problem a `use harmony;` directive can be enough.
    This also will work in non-browser host environments (such as
    CommonJS / Node.js).<br>
    <br>
    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).<br>
    <br>
    So for exactly old browsers the approach with:<br>
    <br>
    &lt;script type="harmony"&gt;<br>
    &lt;/script&gt;<br>
    <br>
    seems good (if not the only possible) since this block won't be even
    parsed/executed.<br>
    <br>
    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 &lt;script type="harmony"&gt; seems wins --
    because the issue mostly touches exactly browser host environments).
    <br>
    <br>
    P.S.: and experiments with &lt;script-if-else&gt; may be leaved for
    more needed cases.<br>
    <br>
    Dmitry.<br>
    <br>
    On 15.10.2010 21:30, Brendan Eich wrote:
    <blockquote
      cite="mid:DD568AE3-5EDF-4065-B419-FDCDAA9A431D@mozilla.com"
      type="cite">
      <div>
        <div>On Oct 14, 2010, at 3:47 PM, Brendan Eich wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div>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:<br>
            <br>
            <a moz-do-not-send="true"
              href="http://wiki.ecmascript.org/doku.php?id=harmony:harmony#means">http://wiki.ecmascript.org/doku.php?id=harmony:harmony#means</a><br>
          </div>
        </blockquote>
        <div><br>
        </div>
        Prior to Means 3(I), there is Goal 4 (<a moz-do-not-send="true"
href="http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals">http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals</a>):</div>
      <div><br>
      </div>
      <div>
        <li class="level1">
          <div class="li">&nbsp;Keep versioning as simple and linear as
            possible.</div>
        </li>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>The minimum opt-in mechanism, we think, is specified by
          RFC4329: &lt;script
          type="application/ecmascript;version=6"&gt;. 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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <blockquote type="cite">
          <div>
            <blockquote type="cite">- Will we have to add yet another
              mode each time we add syntax? After enough iterations this
              becomes unsustainable.<br>
            </blockquote>
            <br>
            Languages don't grow indefinitely but JS syntax (and
            semantics) are gappy enough there could be another edition
            that comes after the first Harmony edition.&nbsp;</div>
        </blockquote>
        <br>
      </div>
      <div>That was a bit too neutral-sounding.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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).</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>My two cents, and as usual I reserve the right to change my
        mind, or coins.</div>
      <div><br>
      </div>
      <div>/be</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>