Addition of a global namespace function?

Mark S. Miller erights at
Fri Dec 4 09:38:53 PST 2009

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...

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.

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.


More information about the es-discuss mailing list