Nested modules clarification
๏̯͡๏ Jasvir Nagra
jas at nagras.com
Fri Jul 20 14:01:19 PDT 2012
On Fri, Jul 20, 2012 at 7:30 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:
> On Fri, Jul 20, 2012 at 10:23 AM, ๏̯͡๏ Jasvir Nagra <jas at nagras.com>
> > 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 ccs.neu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss