Nested modules clarification

๏̯͡๏ Jasvir Nagra jas at
Fri Jul 20 14:01:19 PDT 2012

On Fri, Jul 20, 2012 at 7:30 AM, Sam Tobin-Hochstadt <samth at>wrote:

> On Fri, Jul 20, 2012 at 10:23 AM, ๏̯͡๏ Jasvir Nagra <jas at>
> wrote:
> > I quite liked Erik's suggestion (the Arvidsson transform?) - it's clever.
> > Is the cleverness made necessary because the lexical scope surrounding a
> > module is captured by a module.  As a result, the compiler is forced to
> > compile nested modules to a place where there are no variables to
> > accidentally capture ie. the "top-level" of a module.  In Sam and Dave's
> > original module proposal, IIRC modules were a lexical scope cut-point and
> > thus did not have this issue.
> Just for clarification, this isn't correct -- the proposal has always
> had inner modules inheriting outer scopes.  In the past even
> references to external modules inherited the scope, but we removed
> that because it produces highly confusing results.

Ok got it.  Just summarizing my original questions:

1. What is part of the fresh module scope?  Sam has clarified that it
closes over lexically scoped variables and Dave has clarified that no
variables are closed over in the external case.  What else is included?
 Can an external module utter window?  In a browser, do you expect it to be
able to utter document, getComputedStyle, location?  Can modules
side-effect these globals or is that verboten and the only expected way for
well-behaved modules to return values is via export?

2. Given the semantic hazard possible in inlining, is it worth tweaking the
proposal to address it or is the expectation that to really do code
consolidation into a single file from separate modules, modules require
something more sophisticated that a braindead inliner?

> --
> sam th
> samth at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list