HostGetSource and HostNormalizeModuleName
On Dec 10, 2014, at 4:57 AM, Guy Bedford wrote:
Do the HostGetSource and HostNormalizeModuleName functions allow for asynchronous completion, or are they expected to be synchronous?
Specifically I'd be interested to hear if the browser loader would run its own dependency tree handling or if it should rely on these hooks implicitly managing the dependency tree for it.
The ES6 specification defined the required semantics of the language. It is not intended to be a design sketch for an actual. ES engine. An implementation may perform the abstract operations ParseModuleAndImport and LinkModules for a module (and its dependencies) anytime prior to step 7 of a ModuleEvaluationJob for that module. Whether this is done synchronously or asynchronously is up to the implementation.
Similarly, the distinction between ES abstract operations and Host* abstract operations isn't intended to imply a mandatory implementation separation between the ES engine and a host environment. It is simply making a distinction between what is specified by ES and what must be defined by the implementation.
You question implies that you are thinking from the perspective of some specific design that includes specific separations of responsibility between the ES engine and a "browser loader". I'm not sure that distinction is needed. I would expect the "dependency tree handle" of the "browser loader" to be the (sole) implementation of what ES6 specified as ParseModuleAndImports.
I owe everyone a draft of the loader semantics, but for now here's a way to think about the interface between Ecma-262 and the loader spec: the "names" the ES spec is talking about are not the names used by the loader or in the registry. They are just GUIDs -- you can think of them as just being references to the internal module record, but serialized as GUID strings. AIUI Allen wanted to reify them as strings just to provide a more abstract way for the loader spec to reference module records without actually looking at their internals.
The actual loading happens -- completely asynchronously -- in the loader spec, not in ECMAScript. The HostGetSource and HostNormalizeModuleName are just retrieving an association that's assumed to be provided through other means. Hopefully this will look clearer with an asynchronous loader spec to review.
On Dec 10, 2014, at 12:50 PM, Dave Herman wrote:
I owe everyone a draft of the loader semantics, but for now here's a way to think about the interface between Ecma-262 and the loader spec: the "names" the ES spec is talking about are not the names used by the loader or in the registry. They are just GUIDs -- you can think of them as just being references to the internal module record, but serialized as GUID strings. AIUI Allen wanted to reify them as strings just to provide a more abstract way for the loader spec to reference module records without actually looking at their internals.
Dave, you may not have noticed that in the latest released draft they are called moduleIDs rather than moduleNames.
Do the HostGetSource and HostNormalizeModuleName functions allow for asynchronous completion, or are they expected to be synchronous?
Specifically I'd be interested to hear if the browser loader would run its own dependency tree handling or if it should rely on these hooks implicitly managing the dependency tree for it.