Hi Mike, sorry I overlooked this message.
> | This allows cyclic dependencies between any two modules
> | in a single scope
>
> 1) Is this to say that cycles are allowed, or not allowed, in
> other scenarios? (f ex remote or filesystem-loaded modules)
It's an automatic consequence of lexical scope. It's no different from
functions. If you write:
function f() {
function even(n) { ... odd(n-1) ... }
function g() {
function odd(n) { ... even(n-1) ... }
}
}
you get a scope error, because |even| refers to |odd| which is not in scope.
But if you put them both at the same level of scope, they can refer to each
other. Same deal with modules.
Since MRL's and module names are distinct, there's no problem letting remote
modules refer to one another, they just have to do so through agreed-upon
names. For example:
module Even = "http://zombo.com/even.js";;
module Odd = "http://realultimatepower.net/odd.js";;
By binding them both at the same level of scope, both even.js and odd.js can
refer to Even and Odd.
> 2) Am I understanding this correctly as the module loader
> fetching and registering Lexer.js "on demand" if not already
> present in its registry mapping?
The offline-JS examples are mostly just suggestive; this question is left to
the (host-dependent) module loader to determine. Some offline-JS engines might
prefer to have a module loader that can register top-level names implicitly. It
might also want to load these modules on demand (which is somewhat orthogonal),
but this would likely only be desirable behavior for built-in libraries that
have no observable side effects. (Laziness with side-effects is pain.)
But all of this would require some host-dependent, built-in support; there's
nothing in the spec per se that provides this functionality.
> 3) Is Lexer.js required to contain exactly one module
> declaration that must match the filename, or otherwise an
> exception is thrown?
The short answer is no: the contents are the body of the module.
The long answer is that it depends on the module loader. Module loaders have
hooks that can arbitrarily transform the contents of a module. So a module
loader can decide on whatever format it wants.
Note that when you say "an exception is thrown," this is a compile/load-time
exception. IOW, in the code being loaded, there's no observable exception. But
of course, with dynamic loading, one program's compile-time error is another
program's run-time error. :)
> 4) Would this on demand loading functionality be present
> also on the web platform?
No. We avoided lazy loading in the semantics, because it'd be a hornets' nest
on the web. Modules are eagerly evaluated in deterministic, top-to-bottom
order. As I say above, offline-JS has different needs than web-JS, so in that
context a JS engine may wish to provide a built-in custom module loader that
can deal with the filesystem in more clever ways.
As I replied to Kam Kasravi earlier in this thread, on-demand loading is
achievable via explicit dynamic loading. We tried to be non-clever about doing
this stuff behind programmers' backs.
> 5) If so, would then the uses in main1 and main2 be equivalent
> wrt binding MyLib names in the example below?
>
> // lib/MyLib.js
> module MyLib { export doStuff() ... }
>
> // main1.js
> import lib.MyLib.*;
> doStuff();
>
> // main2.js
> module wrapper = load "lib/MyLib.js";
> import wrapper.MyLib.*;
> doStuff();
No. There'd be no implicit loading on the web.
> 6) If I want to change the previous example to instead expose
> MyLib's names inside a MyLib module name, would I then do
> the following? :
>
> // main1.js
> module MyLib = lib.MyLib;
> MyLib.doStuff();
>
> // main2.js
> module wrapper = load "lib/MyLib.js";
> module MyLib = wrapper.MyLib;
> MyLib.doStuff();
I'm not sure I see what you're getting at, but IIUC, both of those examples are
fine. You can always declare a new module binding that points to/aliases an
existing module binding.
> In the "Remote modules on the web (1)" example we have:
>
> | module JSON = load 'http://json.org/modules/json2.js';
> | alert(JSON.stringify({'hi': 'world'}));
>
> 7) Am I understanding correctly that this is pointing to a
> plain script (without module decls) which is wrapped inside
> the JSON module we specify?
It's a module body, which may contain nested module declarations, variable
declarations, function declarations, statements, etc.
> 8) Imagine a json2mod.js with an embedded:
>
> module JSON { ... }
>
> which would result in:
>
> module JSON = load 'http://json.org/modules/json2mod.js';
> alert(JSON.JSON.stringify({'hi': 'world'}));
>
> Is this assumption correct?
Yes, but you wouldn't wanna do that. ;)
> 9) If so, what syntax could be used to avoid the extra wrapper
> module at load?
The creator of the JSON library doesn't name it; the client names it. The JSON
module just contains the *body* of the module. This is crucial for the web: you
can have millions of libraries without worrying about library name collisions.
> Could there f ex be a standalone load syntax
> that evaluates straight into the current scope:
>
> load 'http://json.org/modules/json2mod.js';
> alert(JSON.stringify({'hi': 'world'}));
You can get partway there via:
module JSON = load 'http://json.org/modules/json2mod.js';
import JSON.*;
But yeah, it might be nice to have a shorthand that avoids the extra module
binding. (I'd probably want the syntax to start with "import" or "module").
> (disclaimer: haven't thought much about implications of this)
Me neither... I'll have to think about it.
> In the "Static module detection" example we have:
>
> | // compiler tries each in order
> | module JSON = load ('JSON' || 'http://json.org/modules/json2.js');
>
> 10) Does this syntax mix module identifiers and MRLs? (the
> 'JSON' item looks very much like a pre-registered module in
> the module registry?)
No, I was just positing some syntax for built-in MRL's. Maybe I should've
written something like
module JSON = load ('browser://JSON' || 'http://json.org/modules/json2.js');
but I didn't want anyone to think I was making some specific proposal for a new
URL scheme or anything. This is one of those things that stands outside the
jurisdiction of TC39 but would still want standardization. I think we're going
to need some amount of (hopefully light) collaboration with a W3C committee.
> 11) [Excuse my poor BNF] What is the +(',') for in:
>
> | ModuleDeclaration ::= 'module' Identifier '=' 'load' MRL+(',') ';'
Heh-- excuse my bogus BNF! That's just a made-up extension that allows 1 or
more instances of MRL, separated by the ',' token. Spelled out:
MRL+(',') ::= MRL
| MRL+(',') ',' MRL
Thanks for your feedback,
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
