On Wed, Jul 10, 2013 at 10:12 PM, Allen Wirfs-Brock
<[email protected]> wrote:
>
> On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote:
>
>> On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
>> <[email protected]> wrote:
>>>
>>> On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
>>>
>>>> On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron <[email protected]>
>>>> 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.)
Yes, we've thought about this. I don't think it changes much, other
than to make the case Mark worried about less prevalent.
> 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.
I believe that this may end up being a distinction without a
difference. When a module is compiled, the names it imports from other
modules must be present, or there's a static error. There's no case
where a module is compiled-but-not-linked, and thus I don't think the
difference would be observable.
> 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?
There are certainly races here, just the way that:
<script async>
x
</script>
races with such dynamic DOM insertions.
Sam
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
