Re: Modules: import *
On Nov 1, 2013, at 6:19 PM, David Herman wrote: > On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote: > >> Now... good use cases could be a sufficient counterargument to all >> this. Maybe we should add `import * from` in 2014. I just want to make >> it totally clear why it's designed this way for ES6. `import * from` >> poses significant problems, both for users and implementations, that >> `export * from` doesn't. > > I do think there's a good change chance ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules: import *
On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote: > Now... good use cases could be a sufficient counterargument to all > this. Maybe we should add `import * from` in 2014. I just want to make > it totally clear why it's designed this way for ES6. `import * from` > poses significant problems, both for users and implementations, that > `export * from` doesn't. Agreed. I do think there's a good change people will start asking for import * more once they've been using the module system, and we can revisit in ES7. There could also be additional technical challenges with lexical modules (if you can say `import * from x` there are weird scoping paradoxes that are hard to eliminate), so it makes sense to wait to reconsider import * until we're dealing with lexical modules. Anyway, this will not be happening for ES6. Let's revisit for ES7. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules: import *
On Thu, Oct 31, 2013 at 12:40 PM, Erik Arvidsson
wrote:
> On Thu, Oct 31, 2013 at 1:22 PM, Jason Orendorff
> wrote:
>> 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.
>
> You have to wait for "stickers" to load to validate the imports anyway.
Right. Validating imports doesn't block compilation though. As long as
you know at compile time that a given identifier *is* an import, you
can just emit a load, and patch that load's target address at link
time.
Or, if it's not an import: in the absence of `import * from`, the use
of the identifier "Math" above could be compiled to code that does
global.[[Get]]("Math"). SpiderMonkey does this today, when all
enclosing non-global scopes are static, which is most of the time.
With `import * from`, we have dynamic scoping until link time—which is
not the end of the world, but it sucks. Dynamic scoping sucks.
But all that is me speaking as an implementer. Humans looking at
modules in isolation also benefit from being able to tell what names
refer to.
[regarding export * from]
> But it has a similar issue. You cannot look at a module in isolation and
> know what it exports.
The issues are abstractly similar, but very different in practice. The
effect of `import * from` on scoping depends on the version of the
module you're importing. Collisions can occur in the future, as your
code, the global object, and the imported module evolve. There's no
way to mitigate.
The effect of `export * from` has no effect on scoping and no
analogous risk of future collisions.
Now... good use cases could be a sufficient counterargument to all
this. Maybe we should add `import * from` in 2014. I just want to make
it totally clear why it's designed this way for ES6. `import * from`
poses significant problems, both for users and implementations, that
`export * from` doesn't.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modules: import *
Thanks, that makes sense. On Thu, Oct 31, 2013 at 1:22 PM, Jason Orendorff wrote: > `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. > You have to wait for "stickers" to load to validate the imports anyway. > > 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. > But it has a similar issue. You cannot look at a module in isolation and know what it exports. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules: import *
On Thu, Oct 31, 2013 at 9:19 AM, Erik Arvidsson 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Modules: import *
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. After using `import *` for over a year in Traceur ( https://github.com/google/traceur-compiler/commit/a8d919eda2d9d0ffd023c37b747cc979734cfaf2#diff-7b327c4c4229665f69afd29a46d100d2) I can tell you that it would be very painful to let go of it. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: modules: import hiding, and usage patterns
On Wed, Feb 8, 2012 at 4:19 PM, Claus Reinke wrote: > Just saw this wiki update (*) Before this goes further, I want to clarify that Dave and I are currently revising the wiki pages, and they're not done yet. We will announce something here when we're done, which should be soon. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
modules: import hiding, and usage patterns
Just saw this wiki update (*)
http://wiki.ecmascript.org/doku.php?id=harmony:modules&do=diff&1328732818
and this sentence:
If there is a conflict between the names from two distinct imports,
and exactly one of the imports uses the ''*'' form, then the other
import takes precedence.
I have two issues with this:
- implicit override instead of ambiguity warning/error
(add an explicit import, and change semantics of implicit
imports elsewhere in the current module, without a type
system to catch the change)
- no way to filter items from the "*" form
(can't resolve ambiguities explicitly)
I would prefer a way to resolve such ambiguities explicitly
by selectively hiding imports (import * hiding {x,y} from M),
with warnings/errors for unresolved ambiguities.
If there is going to be an implicit "import *" from a standard
prelude, it would also be good to have a way to turn the
implicit import into an explicit import (with selective hiding).
Great to see updates to the modules proposal - could you
please have a look at the module usage patterns outlined in
supporting ES upgrading with a programming pattern repo?
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018240.html
It would be nice to see how these patterns will be handled
by ES6 modules (I hope the answer isn't always "use loaders",
but JS coders seem to have grown used to dynamic module
usage patterns which don't seem covered by the static aspects
of ES6 modules).
Finally, about the wiki: the list of old page revisions for each
proposal links to page revisions, not to diffs - am I missing
something, or could the wiki be configured to add diff links
(to previous revision)? Also, the RSS feed still has escaped
URLs, so the links do not lead to the intended page (*).
Claus
(*) the wiki RSS feed url escape problems still persist:
https://mail.mozilla.org/pipermail/es-discuss/2011-April/013927.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
