@@ -106,15 +106,15 @@ inner `func` doesn't need a `core` prefix; the `core` token is used to mark the
106
106
The [ ` core:module ` ] production is unmodified by the Component Model and thus
107
107
components embed Core WebAssembly (text and binary format) modules as currently
108
108
standardized, allowing reuse of an unmodified Core WebAssembly implementation.
109
- The next two productions , ` core:instance ` and ` core:alias ` , are not currently
110
- included in Core WebAssembly, but would be if Core WebAssembly adopted the
111
- [ module-linking ] proposal. These two new core definitions are introduced below,
112
- alongside their component-level counterparts . Finally, the existing
113
- [ ` core:type ` ] production is extended below to add core module types as proposed
114
- for module-linking. Thus, the overall idea is to represent core definitions (in
115
- the AST, binary and text format) as-if they had already been added to Core
116
- WebAssembly so that, if they eventually are, the implementation of decoding and
117
- validation can be shared in a layered fashion.
109
+ The next production , ` core:instance ` , is not currently included in Core
110
+ WebAssembly, but would be if Core WebAssembly adopted the [ module-linking ]
111
+ proposal. This new core definition is introduced below, alongside its
112
+ component-level counterpart . Finally, the existing [ ` core:type ` ] production is
113
+ extended below to add core module types as proposed for module-linking. Thus,
114
+ the overall idea is to represent core definitions (in the AST, binary and text
115
+ format) as-if they had already been added to Core WebAssembly so that, if they
116
+ eventually are, the implementation of decoding and validation can be shared in
117
+ a layered fashion.
118
118
119
119
The next kind of definition is, recursively, a component itself. Thus,
120
120
components form trees with all other kinds of definitions only appearing at the
0 commit comments