On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote:

> On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> 
>> On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
>> 
>>> On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>>>> 
>>>> It gets created nowhere,
>>> 
>>> This is right.
>>> 
>>>> because the body of a module is implicitly strict,
>>> 
>>> And this is right.
>>> 
>>>> so the above code produces a Reference Error.
>>> 
>>> But this is incorrect, because modules check that their bodies don't
>>> have free variables, so the above code has a _static_ error.
>> 
>> Ah, do you mean this is a link time check?
>> 
>> It isn't a regular early error situations because gvar could be a dynamically added property on the global object.
>> 
>> Not sure what your current semantics are, but I thought it was established a long time ago that modules needed free references in order to deal with global object properties.
> 
> No, that's not what I mean.  The semantics we've discussed multiple
> times are that modules are compiled with respect to the global object
> at compilation time, and free variables at that point (ie, compilation
> time) are a static error.  This is implicit in the discussion here:
> http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders (see the
> "global objects" section) and explicit in some of the notes, I'm sure.

Hmm..has this been thought about in light of the decision to structure the global scope into to environment records (a object ER for the global object (and var/function declarations) and a declarative ER for let/consts, etc.)

Also, aren't free references (to globals) quite similar to imports that can't be satisfied at link time.   I can imagine that such free variables could be  treated as implicit imports from the global scope and resolved at the same time and in a similar manner to explicit imports.  There is something that seems more satisfying about all "linking" errors occurring at the same time rather than some occurring as early errors and others occurring as linking errors. 

Finally, are there races between an async script block that define modules and subsequent html elements  with id attributes.  If such a module uses a free global reference to access the DOM node with the matching id won't the occurrence of the compile time error depend upon whether or not the the async script loader gets around to compiler the the script before the html parser gets to the element with the id?

Allen

On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote:

> No, that's not what I mean.  The semantics we've discussed multiple
> times are that modules are compiled with respect to the global object
> at compilation time, and free variables at that point (ie, compilation
> time) are a static error.  This is implicit in the discussion here:
> http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders (see the
> "global objects" section) and explicit in some of the notes, I'm sure.

Hmm..has this been thought about in light of the decision to structure the global scope into to environment records (a object ER for the global object (and var/function declarations) and a declarative ER for let/consts, etc.)

Also, aren't free references (to globals) quite similar to imports that can't be satisfied at link time.   I can imagine that such free variables could be  treated as implicit imports from the global scope and resolved at the same time and in a similar manner to explicit imports.  There is something that seems more satisfying about all "linking" errors occurring at the same time rather than some occurring as early errors and others occurring as linking errors. 

Finally, are there races between an async script block that define modules and subsequent html elements  with id attributes.  If such a module uses a free global reference to access the DOM node with the matching id won't the occurrence of the compile time error depend upon whether or not the the async script loader gets around to compiler the the script before the html parser gets to the element with the id?