Improve code loading and modules section

Author: lukewagner

V1.md

@@ -83,18 +83,33 @@ precise descriptions of:
 
 ## Code loading and imports
  * The loadable unit of WebAssembly code is a *module*.
- * WebAssembly modules can be loaded declaratively (via import on page load) or imperatively (via API call)
-   and can be compiled dynamically (from bytes, as defined by the binary format).
- * A natural integration point with JS would be to have WebAssembly modules be reflected to JS
-   as ES6 Modules.
-   * The module interface would mostly hide whether the module was JS or WebAssembly (except for things 
-     like `fun.toSource()`) and allow webapps to be naturally composed of both JS and WebAssembly modules.
-   * ES6 Modules can be loaded declaratively (via imports) or imperatively (via API calls at runtime).
-   * The ES6 Module API also allows dynamically generated modules (a JS module can be compiled from a string);
-     building on this, WebAssembly modules could be dynamically compiled from an ArrayBuffer.
-   * Just like ES6 modules, WebAssembly modules could import other modules (JS or WebAssembly); this would
-     replace asm.js [FFIs](http://asmjs.org/spec/latest/index.html#external-code-and-data).
- 
+ * Modules can be loaded before execution begins or at runtime.
+ * A module is loaded from a sequence of bytes (specified by the [binary format](V1.md#binary-format))
+   that are either fetched via URL (which can be a filename via file:///) or
+   given in the heap of a running WebAssembly module.
+ * A module can declare a subset of its functions to be exports.
+ * A module can declare that it imports functions (with given names and signatures) from other modules 
+   (with given URLs) and these imports will be recursively loaded when the module is loaded.
+   * An load-time error is raised if the signature of an import does not match the signature of the export.
+   * These imported functions can be called like other internal functions
+     ([directly or indirectly](AstSemantics.md#calls)). 
+ * Modules can be loaded at runtime by WebAssembly code calling a
+   builtin function (implemented by the host environment).
+   * Functions are imported by name/signature with error on mismatch.
+   * These imported functions can only be called [indirectly](AstSemantics.md#calls).
+   * Another builtin function would invalidate all existing function pointer values for a given
+     dynamically-loaded module, allowing it to be unloaded from memory (as soon as it is not active 
+     on the stack and not referenced elsewhere).
+ * All forms of module import produce disjoint [heaps](V1.md#heap) and do not allow function-pointer
+   values to be passed between modules. Thus, separately imported modules are like separate processes
+   that run (and can be synchronously called) on the same thread. 
+   * Support for true native dynamic linking, which requires the ability to load a
+     module into the *same* address space and is a planned [future feature](FutureFeatures.md#dynamic-linking).
+ * In a Web environment, WebAssembly modules are reflected in JS as ES6 modules:
+   * JS can import WebAssembly via `import`, `Reflect` APIs, etc, the same way as ES6 modules;
+   * WebAssembly imports can resolve to ES6 modules; and
+   * WebAssembly modules are loaded with the same [Module Loader pipeline](http://whatwg.github.io/loader/).
+
 ## Heap
  * In v.1, when a WebAssembly module is loaded, it creates a new heap.
    * The [dynamic linking](FutureFeatures.md#dynamic-linking) feature will be necessary for two
@@ -123,8 +138,8 @@ precise descriptions of:
      for portable C/C++ code.
 
 ## Non-browser embedding
- * Host environments can define builtin modules that are implemented natively and thus be imported 
-   directly by WebAssembly modules.
+ * Host environments can define builtin modules that are implemented natively but can otherwise
+   be imported like [other modules](V1.md#code-loading-and-imports).
   * For example, a WebAssembly shell might define a builtin `stdio` library with an export `puts`.
   * Another example, in the browser, would be the WebIDL support mentioned in [future features](FutureFeatures.md).
  * Where there is overlap between the browser and popular non-browser environments, a shared spec could be