On Thu, Oct 31, 2013 at 9:19 AM, Erik Arvidsson
<erik.arvidsson at gmail.com> wrote:
> I know `import * from ModuleSpecifier` was cut to make the module proposal
> simpler. However, we still have `export * from ModuleSpecifier` which has
> most of implementation complications as `import *` does.

`import *` delays full knowledge of what's in the import lexical scope
until link time.  (That is, you can't figure out scopes by looking at
a module in isolation. You have to wait for its dependencies.)

    import * from "stickers";
    ...
        y = r * Math.sin(a);
    ...

It is unclear whether `Math` refers to the global Math or to something
imported from "stickers" at least until "stickers" is loaded.

Similarly, `export * from` delays full knowledge of what's exported
until link time. The practical difference is that a compiler can
benefit from having static scope information up front. Exports really
are not needed until link time.

-j

On Thu, Oct 31, 2013 at 9:19 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
> I know `import * from ModuleSpecifier` was cut to make the module proposal
> simpler. However, we still have `export * from ModuleSpecifier` which has
> most of implementation complications as `import *` does.

`import *` delays full knowledge of what's in the import lexical scope
until link time.  (That is, you can't figure out scopes by looking at
a module in isolation. You have to wait for its dependencies.)

    import * from "stickers";
    ...
        y = r * Math.sin(a);
    ...

It is unclear whether `Math` refers to the global Math or to something
imported from "stickers" at least until "stickers" is loaded.

Similarly, `export * from` delays full knowledge of what's exported
until link time. The practical difference is that a compiler can
benefit from having static scope information up front. Exports really
are not needed until link time.