A few more questions about the current module proposal

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Jul 5 10:34:15 PDT 2012

On Thu, Jul 5, 2012 at 8:06 PM, Russell Leggett
<russell.leggett at gmail.com>wrote:

> Sorry I haven't gotten a chance to get into this thread sooner, let me
> catch up a bit:
> On Wed, Jul 4, 2012 at 2:56 PM, Jussi Kalliokoski <
> jussi.kalliokoski at gmail.com> wrote:
>> On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>>  wrote:
>>> On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
>>> <jussi.kalliokoski at gmail.com> wrote:
>>> >
>>> > 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.
>> Indeed it is, to simplify things. Let's pretend it's a function that gets
>> the text contents of a URL.
>>> > 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.
> So I guess my take on it is that any import statement should be illegal
> inside of eval. Looking at the proposal, that doesn't sound like it,
> though. Let's take the "loadFromUrl" out of the equation.
>     import foo from "baz"
>     var code = 'import foo from "bar"';
>     eval(code);
>     console.log(foo);
> There is a reason why import got special syntax, and it wasn't just so
> that it would be easier to type. Putting it inside eval eliminates any
> ability for static analysis to happen upfront during the parse before
> actually executing. The import dependency cannot be seen, and in this case
> there is a collision on "foo" which should have been detected at
> compilation time. I can think of a dozen other reasons why imports should
> not be allowed in eval, but that's just one which seems like a pretty clear
> problem.

The implications of banning import in eval is that modules for an existing
evaling module loader can't adopt the new modules system, quite possibly
incurring this decision to projects using those modules as well. How much
this would allegedly slow down adoption, I can't tell. Maybe it's

Another thing it means is that eval() would no longer do what it says on
the box, i.e. evaluate an expression of JS, as the code inside eval() would
be a whole different JS.

> On Thu, Jul 5, 2012 at 8:56 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>> One question, though:  branching on the file extension, as above, will
>> not generally work.  The source code might be served through a URL that
>> does not have a file extension.  On the web though, we'll generally have
>> access to a Content-Type header.  In the current design, there's doesn't
>> appear to be a way to get that information.
> This makes a lot of sense to me. Great idea.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/724a68b0/attachment.html>

More information about the es-discuss mailing list