diff --git a/spec.emu b/spec.emu index 3acbc58..65c248c 100644 --- a/spec.emu +++ b/spec.emu @@ -61,7 +61,7 @@ contributors: Steven, Guy Bedford
Let _type_ be _entry_.[[Value]].
If _type_ is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.
If _type_ is *"buffer"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of CreateBufferModule or a throw completion.
If _type_ is *"bytes"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of CreateBytesModule or a throw completion.
The actual process performed is host-defined, but typically consists of performing whatever I/O operations are necessary to load the appropriate Module Record. Multiple different (_referrer_, _moduleRequest_.[[Specifer]], _moduleRequest_.[[Attributes]]) triples may map to the same Module Record instance. The actual mapping semantics is host-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as expansion of relative and abbreviated path specifiers.
The above text implies that hosts *must* support JSON modules and buffer modules imported with `type: "json"` and `type: "buffer"` respectively (if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.
+The above text implies that hosts *must* support JSON modules and bytes modules imported with `type: "json"` and `type: "bytes"` respectively (if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.
All of the import statements in the module graph that address the same JSON or buffer module may evaluate to the same mutable object.
+All of the import statements in the module graph that address the same JSON or bytes module may evaluate to the same mutable object.
A Synthetic Module Record is used to represent information about a module that is defined by specifications. Its exports are derived from a pair of lists, of string keys and of ECMAScript values. The set of exported names is static, and determined at creation time (as an argument to CreateSyntheticModule), while the set of exported values can be changed over time using SetSyntheticModuleExport. It has no imports or dependencies.
-In addition to the fields defined in