Addition of a global namespace function?

Mike Samuel mikesamuel at
Fri Dec 4 13:52:08 PST 2009

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

> Regards
>> Given that primordials (other than the global object) are transitively
>> frozen and that the above whitelist was adequately restrictive, each
>> call of a closed function is fully isolated -- its connectivity to the
>> world outside itself is fully under control of its caller. If the
>> module-function's caller denies access to the global object, the
>> indirect eval function, and to the Function constructor, then the
>> module cannot pollute non-local state.
>> --
>>  Cheers,
>>  --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list