A few more questions about the current module proposal

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Jul 5 11:10:30 PDT 2012


On Thu, Jul 5, 2012 at 8:59 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:

> On Wed, Jul 4, 2012 at 2:56 PM, Jussi Kalliokoski
> <jussi.kalliokoski at gmail.com> wrote:
> >> > 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).
> >
> > 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.
>
> There's a `Loader.evalAsync(src, cb)` method which supports fetching
> remote resources using `import` statements.
>
> The alternatives would be one of:
>  - banning reference to remote data except using callbacks
>  - making `eval` do synchronous IO
>
> I think both of those are much worse.
>

Ahah! This is why I ask, forgive my ignorance! :) This is excellent, I'll
withdraw my argument as evalAsync solves my problem. You're absolutely
correct, now I very much agree that import should be banned from eval. An
existing evaling module loader can just be updated to use evalAsync.

>
> >> > 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.
> >
> >
> > 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.
>
> Yes, translation is to the full JS language.  Of course,
> CoffeeScript's interface to the JS module system is up to Jeremy, not
> Dave and me, to decide.
>

Excellent.


> > 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.
>
> There's no tension between static resolution and allowing the loader
> to change dynamically -- I've posted lots of code using `System.set`,
> for example.  Making the default system loader arbitrarily mutable has
> many other potential problems, though: it makes it harder for engine
> implementers to optimize, it potentially raises security holes, it
> lets any code on the page change the meaning of all the rest of the
> code on the page.  But fundamentally, that's about the design of the
> System loader, and we can improve that without having to change the
> fundamental aspects of the design (that's one of the nice aspects of
> the system).
>

I see. Very good. Let's hope the JS built-in modules win the race.

Cheers,
Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/5d291c91/attachment-0001.html>


More information about the es-discuss mailing list