Thanks for the detailed explanations, David. Here's a few follow- up questions (with "done" questions snipped out):
David Herman wrote: > > | 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) > <snip> > 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. Agreed, but I was rather wondering about cases like: even.js module Odd = "odd.js"; ... odd.js module Even = "even.js"; ... >From other discussion I'm guessing this kind of circular referencing will not be supported? > > 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.) Right, the modules importable through this syntax would thus be considered "pre-registered" in some sense. > > 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. <snip> I'm still a little confused by the rules here, but assuming a naive loader implementation, what would the following result in? (bonus points for describing how you envision a made-up setup process): // compiler/Lexer.js module Lexer { ... } module Tokenizer { ... } ... // Main.js import compiler.Tokenizer.*; > > 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. I don't find a definition for "module body" in your strawman. Are you meaning that http://json.org/modules/json2.js above is organized as: function stringify... function parse... or as export function stringify... export function parse... (although this is invalid according to the grammar) or as something else? > > 9) If so, what syntax could be used to avoid the extra wrapper > > module at load? > <snip> > 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"). It would be nice with a unified syntax for module "sub-addressing" that looks the same both when loading a new module or when aliasing an existing module. > > 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. Two random thoughts on this: - I think it would be suitable with some special marker when addressing built-ins, as module JSON = load "JSON"; might as well be used for relative addressing to the ./JSON application URL, which should issue an external request. - For the web it is probably not interesting to do this resolution for anything else than built-ins and *one* external URL. Providing a search path with multiple external URLs would mean depending on hitting 404s as part of the load phase, which is usually frowned upon. Best regards Mike _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
