On 5 October 2014 17:51, Brian Di Palma <[email protected]> wrote:
> 1) I think you mean that a parser wants to fail quickly if it comes
> across an identifier that was not previously declared as an import but
> that could be declared as one deeper in the module file? The simple
> solution to that problem is to not allow binding references before
> their import statements.
No, fail fast is not the issue, nor is the recursive nature of scoping
in JavaScript.
The issue is that, in order to know what identifiers are bound -- even
in the simplest, linear case -- you need to maintain environments,
i.e., do analysis and bookkeeping of declarations and scopes, both
surrounding and local ones. So far, "pre-parsing" (the early
approximate parse of lazily compiled functions, that only looks for
early errors) didn't need anything like that. Adding it probably isn't
overly expensive, but it's not free either, and nobody has measured
the impact on large applications.
> 99.9% of modules will declare their imports at the top of the file
> anyway, most developers won't come across this restriction very often.
> It doesn't take away functionality, it's a useless degree of freedom
> and I can't think of any language where it's good practice to
> import/require etc anywhere but at the head of a module/class.
It's not just imports, you can forward reference any declaration in
JavaScript. That's a feature that cannot easily be removed, and
binding analysis has to deal with it. It's not a problem, though, only
a mild complication.
> 2) I didn't explain this part well. I meant for the "@global" import
> to be a special one who's bindings will not go through the same checks
> that other modules do. In a browser importing global would return
> window.
>
> This should make it trivial to upgrade current code to ES6 modules
> while still allowing much stricter checks in modules.
> You would use tools that take the ES5 code and scan it for free
> identifiers and import them from "@global".
> This then allows you to gradually move them all into ES6 modules.
>
> import * as global, {Date, XMLHttpRequest} from "@global";
>
> All bindings provided by "@global" bypass the normal bindings checks.
IIUC, your suggestion is that modules should be closed, i.e., not be
able to refer to any non-local or pre-defined identifiers. This idea
has a long history in works on module systems, but I'm not aware of
any practical language that ever managed to follow it through. It
quickly becomes very tedious in practice, and I highly doubt it would
jive well with JavaScript, or probably any language (although Gilad
Bracha disagrees on the latter).
/Andreas
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
