No subject

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