A few more questions about the current module proposal

Sam Tobin-Hochstadt samth at ccs.neu.edu
Wed Jul 4 11:13:47 PDT 2012


On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
<jussi.kalliokoski at gmail.com> wrote:
> Hello, good people,
>
> I fear I have some misunderstanding going on with the current module
> proposal, as well as outright ignorance, hence I'd like to get answers to a
> few questions, as I'm pretty sure I'm not the only one. :)
>
> 1) How does the static resolution and static scoping behave when out of the
> normal context. As an example if `import` is in an `eval()` call, what would
> happen:
>
> var code = loadFromURL('http://example.org/foo.js') // content: `import foo
> from "bar"`
> eval(code)
> console.log(foo) // ???

First, what does `loadFromURL` do?  That looks like sync IO to me.

> Would this example block until the module is resolved and loaded? Would it
> throw? What happens, exactly? As my $0.02 goes, I think it's a bad idea to
> ban import in eval.

Second, it depends on whether "bar" is a previously-loaded module.
For example, if "bar" is a library provided by the host environment,
such as the browser, then everything will be fine, and the code will
import `foo` successfully.  If "bar" is a remote resource, this will
throw -- we're not going to add synchronous IO to `eval` (or to
anything else).

> 2) How does the module proposal address the increasing need for interaction
> between pure JS and compile-to-JS languages? (CoffeeScript, Haxe, JS++, JS*,
> etc)?
>
> More specifically, can you add hooks to preprocessing the files? If not,
> why? I think it would break static module resolution, but are we certain
> that static module resolution is worth the price of excluding JS
> preprocessors of the module system (aside from server-side preprocessing
> that is)? Again, my personal opinion is that including compile-to-JS
> languages in the module system would be worth much more than static
> resolution, but feel free to enlighten me.

We've thought a lot about compile-to-JS languages, and a bunch of the
features of the module loader system are there specifically to support
these languages.  You can build a loader that uses the `translate`
hook to perform arbitrary translation, such as running the
CoffeeScript compiler, before actually executing the code.  So you'll
be able to write something like this:

let CL = new CoffeeScriptLoader();
CL.load("code/something.coffee", function(m) { ... });

There are two ways to potentially make this more convenient.  One
would be to add something to HTML to declare the loader to be used
with particular script tags, which we've talked about, but I think we
should wait on until we have the base module system in place.  The
other would be to ship some of these loaders in browsers, but if I was
the author of a compile-to-JS language, I wouldn't want to be chained
to browser release and upgrade schedules.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list