Addition of a global namespace function?

Mike Samuel mikesamuel at
Fri Dec 4 14:15:16 PST 2009

2009/12/4 Alex Russell <alex at>:
> On Dec 4, 2009, at 1:52 PM, Mike Samuel wrote:
>> 2009/12/4 Alex Russell <alex at>:
>>> On Dec 4, 2009, at 9:38 AM, Mark S. Miller wrote:
>>>> On Fri, Dec 4, 2009 at 8:41 AM, Alex Russell <alex at>
>>>> wrote:
>>>>> CommonJS modules don't solve the global pollution problem, because they
>>>>> can't. We're gonna keep blowing off limbs until we acknowledge that
>>>>> there's
>>>>> a design flaw in the language and take some positive action at a
>>>>> semantic
>>>>> level to correct it.
>>>> ES5 allows one to enumerate all properties on primordial objects
>>>> except the global (window) object, to attempt to delete all properties
>>>> that are absent from a whitelist or die trying, and then to attempt
>>>> freeze all these cleaned up primordials (including all objects
>>>> reachable by traversal of remaining properties) or die trying. If both
>>>> of these succeed...
>>> ...then you still can't keep someone from plunking something into window.
>>> for only their context. Not that you'd want to, but the language still
>>> makes
>>> you work harder than not to do the right thing. A missing "var" still
>>> screws
>>> the pooch.
>> Such a var would not pass the verifier.
>>>> ES5-strict enables to do a fully static scope analysis. Say one builds
>>>> a static verifier for Program text that does nothing but reject text
>>>> that either 1) is not a valid ES5-strict program unit, 2) has free
>>>> variables, or 3) uses a direct eval operator. A "closed function" is a
>>>> function that has no free variables. The natural rewrite of a module
>>>> is as the body of a closed function, perhaps packaged in a larger
>>>> closed expression or Program that would pass the above verifier.
>>>> Because ES5-strict is statically scoped, such a verifier effectively
>>>> removes the global object from the bottom of the scope chain of
>>>> Programs that pass this verifier.
>>> Again, it's good that we can do it now, but the default policy hasn't
>>> changed, you you'll forgive me if I'm somewhat skeptical that opening the
>>> door alone will bring in the thundering herds.
>> Rewriters can bridge the gap between correct verifier and
>> not-quite-correct code, by, e.g. introducing var declarations for free
>> variables.
> Rephrased slightly for the entertainment of 3rd parties:
>  me:  the problem is that people can still omit var
>  you: everyone will run it through a verifier
>  me: programmers are still human, particularly web developers. They don't
> run verifiers. In general we still have the problem.0
>  you: everyone will run it through a verifier
>  me:  really? And if they're going to accept the constraint anyway, wouldn't
> it be better if we just created a construct where the default is changed?
>  you: but everyone can just run it through a verifier!
>  me:  um...

No, this is a strawman.

For micky mouse applications, module systems don't matter.
But they matter a great deal for complex applications that are trying
to combine the work of many people into a coherent whole.
Those projects tend to have someone who maintains a build system.

The goal of a module system is to provide separation.
The person who bundles the modules into a program is the one who wants
to guarantee separation.
So the verifier/rewriter is run by the deployer of the application.
Not the library writer or the UI developer.
Just the build manager.

Not every project.  Just complex projects where coordination requires
module management.

> Lawls.

More information about the es-discuss mailing list