Merge pull request #44 from WebAssembly/add-core-alias-declarators

Add <core:alias> to <core:moduledecl>

Author: lukewagner

design/mvp/Binary.md

@@ -131,6 +131,7 @@ core:deftype    ::= ft:<core:functype>                     => ft               (
 core:moduletype ::= 0x50 md*:vec(<core:moduledecl>)        => (module md*)
 core:moduledecl ::= 0x00 i:<core:import>                   => i
                   | 0x01 t:<core:type>                     => t
+                  | 0x02 a:<core:alias>                    => a
                   | 0x03 e:<core:exportdecl>               => e
 core:importdecl ::= i:<core:import>                        => i
 core:exportdecl ::= n:<name> d:<core:importdesc>           => (export n d)
@@ -140,8 +141,11 @@ Notes:
 * Validation of `core:moduledecl` (currently) rejects `core:moduletype` definitions
   inside `type` declarators (i.e., nested core module types).
 * As described in the explainer, each module type is validated with an
-  initially-empty type index space. Outer aliases can be used to pull
-  in type definitions from containing components.
+  initially-empty type index space.
+* Validation of `alias` declarators only allows `outer` `type` aliases.
+  Validation of these aliases cannot see beyond the enclosing core type index
+  space. Since core modules and core module types cannot nest in the MVP, this
+  means that the maximum `ct` in an MVP `alias` declarator is `1`.
 
 ```
 type          ::= dt:<deftype>                         => (type dt)

design/mvp/Explainer.md

@@ -357,6 +357,7 @@ core:deftype    ::= <core:functype>                           (WebAssembly 1.0)
 core:moduletype ::= (module <core:moduledecl>*)
 core:moduledecl ::= <core:importdecl>
                   | <core:type>
+                  | <core:alias>
                   | <core:exportdecl>
 core:importdecl ::= (import <name> <name> <core:importdesc>)
 core:exportdecl ::= (export <name> <core:exportdesc>)
@@ -387,7 +388,7 @@ type imports local to the module type itself. For example, in the future, the
 following module type would be expressible:
 ```
 (component $C
-  (type $M (module
+  (core type $M (module
     (import "" "T" (type $T))
     (type $PairT (struct (field (ref $T)) (field (ref $T))))
     (export "make_pair" (func (param (ref $T)) (result (ref $PairT))))
@@ -398,6 +399,36 @@ In this example, `$M` has a distinct type index space from `$C`, where element
 0 is the imported type, element 1 is the `struct` type, and element 2 is an
 implicitly-created `func` type referring to both.
 
+Lastly, the `core:alias` module declarator allows a module type definition to
+reuse (rather than redefine) type definitions in the enclosing component's core
+type index space via `outer` `type` alias. In the MVP, validation restricts
+`core:alias` module declarators to *only* allow `outer` `type` aliases but,
+in the future, more kinds of aliases would be meaningful and allowed.
+
+As an example, the following component defines two semantically-equivalent
+module types, where the former defines the function type via `type` declarator
+and the latter refers via `alias` declarator. Note that, since core type
+definitions are validated in a Core WebAssembly context that doesn't "know"
+anything about components, the module type `$C2` can't name `$C` directly in
+the text format but must instead use the appropriate [de Bruijn] index (`1`).
+In both cases, the defined/aliased function type is given index `0` since
+module types always start with an empty type index space.
+```wasm
+(component $C
+  (core type $C1 (module
+    (type (func (param i32) (result i32)))
+    (import "a" (func (type 0)))
+    (export "b" (func (type 0)))
+  ))
+  (core type $F (func (param i32) (result i32)))
+  (core type $C2 (module
+    (alias outer 1 $F (type))
+    (import "a" (func (type 0)))
+    (export "b" (func (type 0)))
+  ))
+)
+```
+
 Component-level type definitions are symmetric to core-level type definitions,
 but use a completely different set of value types. Unlike [`core:valtype`]
 which is low-level and assumes a shared linear memory for communicating
@@ -542,28 +573,6 @@ When [resource and handle types] are added to the explainer, `typebound` will
 be extended with a `sub` option (symmetric to the [type-imports] proposal) that
 allows importing and exporting *abstract* types.
 
-Lastly, component and instance types also include an `alias` declarator for
-projecting the exports out of imported instances and sharing types with outer
-components. As an example, the following component defines two equivalent
-component types, where the former defines the function type via `type`
-declarator and the latter via `alias` declarator. In both cases, the type is
-given index `0` since component types start with an empty type index space.
-```wasm
-(component $C
-  (type $C1 (component
-    (type (func (param string) (result string)))
-    (import "a" (func (type 0)))
-    (export "b" (func (type 0)))
-  ))
-  (type $F (func (param string) (result string)))
-  (type $C2 (component
-    (alias outer $C $F (type))
-    (import "a" (func (type 0)))
-    (export "b" (func (type 0)))
-  ))
-)
-```
-
 With what's defined so far, we can define component types using a mix of inline
 and out-of-line type definitions:
 ```wasm