No more modes?

Dmitry A. Soshnikov dmitry.soshnikov at
Mon Oct 18 03:47:31 PDT 2010

  P.S.[2]: 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?

P.S.[3] @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 
> / Node.js).
> 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">
> </script>
> seems good (if not the only possible) since this block won't be even 
> parsed/executed.
> 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 cases.
> Dmitry.
> 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 edition.
>> 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 
>> coins.
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list