@@ -2993,7 +2986,7 @@ 2.8 ModuleRequest Records
- [[Specifier]]
+ [[Specifier]]
|
String
@@ -3004,10 +2997,10 @@ 2.8 ModuleRequest Records
|
- [[Assertions]]
+ [[Assertions]]
|
- a List of Records { [[Key]]: a String, [[Value]]: a String }
+ a List of Records { [[Key]]: a String, [[Value]]: a String }
|
The import assertions
@@ -3036,7 +3029,7 @@ 2.8 ModuleRequest Records
|
- [[Status]]
+ [[Status]]
|
unlinked | linking | linked | evaluating | evaluated
@@ -3047,41 +3040,41 @@ 2.8 ModuleRequest Records
|
- [[EvaluationError]]
+ [[EvaluationError]]
|
An abrupt completion | undefined
|
- A completion of type throw representing the exception that occurred during evaluation. undefined if no exception occurred or if [[Status]] is not evaluated.
+ A completion of type throw representing the exception that occurred during evaluation. undefined if no exception occurred or if [[Status]] is not evaluated.
|
- [[DFSIndex]]
+ [[DFSIndex]]
|
Integer | undefined
|
Auxiliary field used during Link and Evaluate only.
- If [[Status]] is linking or evaluating, this nonnegative number records the point at which the module was first visited during the ongoing depth-first traversal of the dependency graph.
+ If [[Status]] is linking or evaluating, this nonnegative number records the point at which the module was first visited during the ongoing depth-first traversal of the dependency graph.
|
- [[DFSAncestorIndex]]
+ [[DFSAncestorIndex]]
|
Integer | undefined
|
- Auxiliary field used during Link and Evaluate only. If [[Status]] is linking or evaluating, this is either the module's own [[DFSIndex]] or that of an "earlier" module in the same strongly connected component.
+ Auxiliary field used during Link and Evaluate only. If [[Status]] is linking or evaluating, this is either the module's own [[DFSIndex]] or that of an "earlier" module in the same strongly connected component.
|
- [[RequestedModules]]
+ [[RequestedModules]]
|
List of StringModuleRequest Record
@@ -3111,7 +3104,7 @@ 2.8 ModuleRequest Records
|
- [[ModuleRequest]]
+ [[ModuleRequest]]
|
String
@@ -3124,18 +3117,18 @@ 2.8 ModuleRequest Records
|
- [[ImportName]]
+ [[ImportName]]
|
String
|
- The name under which the desired binding is exported by the module identified by [[ModuleRequest]]. The value "*" indicates that the import request is for the target module's namespace object.
+ The name under which the desired binding is exported by the module identified by [[ModuleRequest]]. The value "*" indicates that the import request is for the target module's namespace object.
|
- [[LocalName]]
+ [[LocalName]]
|
String
@@ -3160,7 +3153,7 @@ 2.9 Static Semantics: ModuleRequests
- Return ModuleRequests of FromClause.- Let specifier be StringValue of the StringLiteral contained in FromClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: an empty List }.
+ Return ModuleRequests of FromClause.- Let specifier be StringValue of the StringLiteral contained in FromClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: an empty List }.
ImportDeclaration :
import
@@ -3171,7 +3164,7 @@ 2.9 Static Semantics: ModuleRequests
- - Let specifier be StringValue of the StringLiteral contained in FromClause.
- Let assertions be AssertClauseToAssertions of AssertClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: assertions }.
+ - Let specifier be StringValue of the StringLiteral contained in FromClause.
- Let assertions be AssertClauseToAssertions of AssertClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: assertions }.
Module : [empty]
@@ -3205,7 +3198,7 @@ 2.9 Static Semantics: ModuleRequests
- Return ModuleRequests of FromClause.- Let specifier be StringValue of the StringLiteral contained in FromClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: an empty List }.
+ Return ModuleRequests of FromClause.- Let specifier be StringValue of the StringLiteral contained in FromClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: an empty List }.
ExportDeclaration :
export
@@ -3216,7 +3209,7 @@ 2.9 Static Semantics: ModuleRequests
- - Let specifier be StringValue of the StringLiteral contained in FromClause.
- Let assertions be AssertClauseToAssertions of AssertClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: assertions }.
+ - Let specifier be StringValue of the StringLiteral contained in FromClause.
- Let assertions be AssertClauseToAssertions of AssertClause.
- Return a ModuleRequest Record { [[Specifer]]: specifier, [[Assertions]]: assertions }.
ExportDeclaration :
export
@@ -3262,8 +3255,8 @@ A Sample host integration: The Web embedding
The module script would have an additional item, which would be the module type, as a string (e.g., "json"), or undefined for a JavaScript module.
- HostLoadImportedModule would take a ModuleRequest Record parameter in place of a specifier string, which would be passed down through several abstract operations to reach the fetch a single module script algorithm. Somewhere near the entrypoint, if the ModuleRequest Record's [[Assertions]] field has an element entry such that entry.[[Key]] is "type", then let type be entry.[[Value]]; otherwise let type be undefined. If the type is invalid, then an exception is thrown and module loading fails. Otherwise, this will equal the module type, if the module can be successfully fetched with a matching MIME type.
- In the fetch the descendents of a module script algorithm, when iterating over [[RequestedModules]], the elements are ModuleRequest Records rather than just specifier strings; these Records is passed on to the internal module script graph fetching procedure (which sends it to "fetch a single module script". Other usage sites of [[RequestedModules]] ignore the assertion.
+ HostLoadImportedModule would take a ModuleRequest Record parameter in place of a specifier string, which would be passed down through several abstract operations to reach the fetch a single module script algorithm. Somewhere near the entrypoint, if the ModuleRequest Record's [[Assertions]] field has an element entry such that entry.[[Key]] is "type", then let type be entry.[[Value]]; otherwise let type be undefined. If the type is invalid, then an exception is thrown and module loading fails. Otherwise, this will equal the module type, if the module can be successfully fetched with a matching MIME type.
+ In the fetch the descendents of a module script algorithm, when iterating over [[RequestedModules]], the elements are ModuleRequest Records rather than just specifier strings; these Records is passed on to the internal module script graph fetching procedure (which sends it to "fetch a single module script". Other usage sites of [[RequestedModules]] ignore the assertion.
"Fetch a single module script" would check the assertion in two places:
- The module map is keyed with both the absolute URL and the module type, so an existing entry will be found only if its type matches.
diff --git a/spec.emu b/spec.emu
index 183266b..1b8a982 100644
--- a/spec.emu
+++ b/spec.emu
@@ -139,16 +139,6 @@
If this operation is called multiple times with the same (_referrer_, _specifier_) pair(_referrer_, _moduleRequest_.[[Specifier]], _moduleRequest_.[[Assertions]]) triple and it performs FinishLoadingImportedModule(_referrer_, _specifier__moduleRequest_, _payload_, _result_) where _result_ is a normal completion, then it must perform FinishLoadingImportedModule(_referrer_, _specifier__moduleRequest_, _payload_, _result_) with the same _result_ each time.
-
- It is recommended but not required that implementations additionally conform to the following stronger constraint:
-
- -
- If this operation is called multiple times with the same (_referrer_, _moduleRequest_.[[Specifier]]) pair and it performs FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) where _result_ is a normal completion, then it must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) with the same _result_ each time.
-
-
-
-
- _moduleRequest_.[[Assertions]] must not influence the interpretation of the module or the module specifier; instead, it may be used to determine whether the algorithm completes normally or with an abrupt completion.
The operation must treat _payload_ as an opaque value to be passed through to FinishLoadingImportedModule.
@@ -157,13 +147,12 @@
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_, _specifier__moduleRequest_.[[Specifier]]) pairs may map to the same Module Record instance. The actual mapping semantic is host-defined but typically a normalization process is applied to _specifier__moduleRequest_.[[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 is recommended but not required that hosts do not use _moduleRequest_.[[Assertions]] as part of the module cache key. In either case, an exception thrown from an import with a given assertion list does not rule out success of another import with the same specifier but a different assertion list.
- Assertions do not affect the contents of the module. Future follow-up proposals may relax this restriction with "evaluator attributes" that would change the contents of the module. There are three possible ways to handle multiple imports of the same module with "evaluator attributes":
+
+ When the same specifier is imported multiple times with different attributes, hosts could choose between three possible behaviors:
- Race and use the attribute that was requested by the first import. This seems broken--the second usage is ignored.
- - Reject the module graph and don't load if attributes differ. This seems bad for composition--using two unrelated packages together could break, if they load the same module with disagreeing attributes.
- - Clone and make two copies of the module, for the different ways it's transformed. In this case, the attributes would have to be part of the cache key. These semantics would run counter to the intuition that there is just one copy of a module.
+ - Reject the module graph and don't load if attributes are incompatible. This seems bad for composition--using two unrelated packages together could break, if they load the same module with disagreeing attributes.
+ - Clone and make two copies of the module, for the different ways it's transformed. These semantics would run counter to the intuition that there is just one copy of a module.
It's possible that one of these three options may make sense for a module load, on a case-by-case basis by attribute, but it's worth careful thought before making this choice.
|