On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt <span dir="ltr"><<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski<br>
<<a href="mailto:jussi.kalliokoski@gmail.com">jussi.kalliokoski@gmail.com</a>> wrote:<br>
> Hello, good people,<br>
><br>
> I fear I have some misunderstanding going on with the current module<br>
> proposal, as well as outright ignorance, hence I'd like to get answers to a<br>
> few questions, as I'm pretty sure I'm not the only one. :)<br>
><br>
> 1) How does the static resolution and static scoping behave when out of the<br>
> normal context. As an example if `import` is in an `eval()` call, what would<br>
> happen:<br>
><br>
> var code = loadFromURL('<a href="http://example.org/foo.js" target="_blank">http://example.org/foo.js</a>') // content: `import foo<br>
> from "bar"`<br>
> eval(code)<br>
> console.log(foo) // ???<br>
<br>
</div>First, what does `loadFromURL` do?  That looks like sync IO to me.<br></blockquote><div><br>Indeed it is, to simplify things. Let's pretend it's a function that gets the text contents of a URL.<br></div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Would this example block until the module is resolved and loaded? Would it<br>
> throw? What happens, exactly? As my $0.02 goes, I think it's a bad idea to<br>
> ban import in eval.<br>
<br>
</div>Second, it depends on whether "bar" is a previously-loaded module.<br>
For example, if "bar" is a library provided by the host environment,<br>
such as the browser, then everything will be fine, and the code will<br>
import `foo` successfully.  If "bar" is a remote resource, this will<br>
throw -- we're not going to add synchronous IO to `eval` (or to<br>
anything else).<br></blockquote><div><br>So basically, eval()'ing something acquired via XHR would no longer give the same result as it does if the same script is in a script tag? Suffice to say I disagree strongly with this choice, but I'm sure the rationale behind this choice is strong.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 2) How does the module proposal address the increasing need for interaction<br>
> between pure JS and compile-to-JS languages? (CoffeeScript, Haxe, JS++, JS*,<br>
> etc)?<br>
><br>
> More specifically, can you add hooks to preprocessing the files? If not,<br>
> why? I think it would break static module resolution, but are we certain<br>
> that static module resolution is worth the price of excluding JS<br>
> preprocessors of the module system (aside from server-side preprocessing<br>
> that is)? Again, my personal opinion is that including compile-to-JS<br>
> languages in the module system would be worth much more than static<br>
> resolution, but feel free to enlighten me.<br>
<br>
</div>We've thought a lot about compile-to-JS languages, and a bunch of the<br>
features of the module loader system are there specifically to support<br>
these languages.  You can build a loader that uses the `translate`<br>
hook to perform arbitrary translation, such as running the<br>
CoffeeScript compiler, before actually executing the code.  So you'll<br>
be able to write something like this:<br>
<br>
let CL = new CoffeeScriptLoader();<br>
CL.load("code/something.coffee", function(m) { ... });<br>
<br>
There are two ways to potentially make this more convenient.  One<br>
would be to add something to HTML to declare the loader to be used<br>
with particular script tags, which we've talked about, but I think we<br>
should wait on until we have the base module system in place.  The<br>
other would be to ship some of these loaders in browsers, but if I was<br>
the author of a compile-to-JS language, I wouldn't want to be chained<br>
to browser release and upgrade schedules.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Okay, seems like it's a solution of a sort. Next question is that does this mean that for example CoffeeScript programs will be able to use pure JS modules using the import statement? i.e. can the translated code contain an import statement? If yes, as I presume, good.<br>
<br>Still, this is nowhere near the convenience of node's require() and the possibility of adding a new preprocessor just using require.registerExtension() and after that you have the same require() for a new language. I guess we'll see whether that convenience will outweigh the benefits of static resolution.<br>
<br>And btw, please don't mistake my concern for negativity, I really appreciate the extremely hard work behind the current proposal; but I'd hate to see it not ending up superior to the existing module systems (i.e. making them useless), becoming just another module system library authors have to support and for which to provide different versions, as well as just another module system developers need to know how to use because a third-party module they use works only with it. That fragmentation cost would imho be far worse than not having a standardized modules at all (for now), but I guess we'll find out whether it's a hit or a miss only after it's already there.<br>
<br>Thanks for answering my questions!<br><br>Cheers,<br>Jussi<br></div></div>