Four static scoping violations in ES5 sloppy

David Bruant bruant.d at
Mon Mar 18 09:59:39 PDT 2013

Le 18/03/2013 17:48, Brendan Eich a écrit :
> Andreas Rossberg wrote:
>> On 18 March 2013 17:32, Mark S. Miller<erights at>  wrote:
>>> And why does ES5/strict impose these restrictions, when they are not
>>> necessary for the formal criterion?
>>> Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
>>> clean things up in preparation for yet better scoping in ES6. I'm 
>>> pleased to
>>> report that it mostly turned out that way. Because of #1 and #3, ES5 
>>> strict
>>> code will be easier to refactor into ES6 modules, where the global 
>>> object is
>>> finally not on their scope chain. At the time we did this, we didn't
>>> anticipate this specific aspect of ES6, but took the opportunity to 
>>> clear
>>> the ground.
>> Maybe I misunderstand what you mean, but unfortunately, the global
>> object will remain at the top of the scope chain in ES6, even with
>> modules (though complemented with a lexical environment for new
>> binding forms). We shied away from fixing that mistake.
> Don't break the web.
> Versioning is an anti-pattern.
> I don't think "shied away" is accurate. We couldn't fix that mistake.
I don't understand the mention of "don't break the web". Modules aren't 
used on the web, so whatever rules are chosen for them they can't break 
the web.
I'm probably missing something here.

Maybe "global in the scope chain" has to be divided into 2 different 
meanings: "read" and "write" to the global scope.
My current understanding is as follow:
* code in a module body can read globals in the global scope
* code in a module cannot create a global properties (unless being hand 
off the global object specifically)
* the module name is part of the newly introduced lexical binding ("file 
local" global variables).

How far am I in understanding modules and scoping?


More information about the es-discuss mailing list