ModuleDeclarationInstantiation behaviour after failure

Jon Coppeard jcoppeard at
Wed Jul 20 15:47:30 UTC 2016

On 18/07/2016 19:04, Allen Wirfs-Brock wrote:
> The intent is that after the “host” has fetched a module (and its
> dependencies) it enqueue a TopLevelModuleEvaluationJob. 

OK, so calling EnqueueJob with a TopLevelModuleEvaluationJob is how this
is supposed to happen.

That doesn't give an indication of whether the job succeeded though
(except for the fact that it would call HostReportErrors some time
later).  Is it possible to to find out whether this was successful
without relying on implementation-specific behaviour?

> In a loader spec. that is expect to have multiple implementations (eg,
> the HTML module loader) you want to be careful to not over-specify
> things that should be implementation details.

I agree.  My concern is that since this is a complex and subtle area
under-specifying this could lead to differences in behaviour between

> The primary interface from the ES spec. back into a loader
> is .  ES
> expect to get a Module Record for a fully parsed/analyzed source module
> back from that.  Something that isn’t said there (but probably should
> be) is that if the referenced module is is a source text module (there
> can be other, host/implementation defined kinds of modules that are
> defined using the ES Module grammar) then ParseModule must be “called”
> to produce the corresponding Source Text Module Record.
> I would expect any  host spec. for MostResolveImportedModule to roughly
> follow this pattern:
>  1.   Use /referencingModule/ and /specifier/ to obtain a host internal
>     module id, /mid/.
>  2.   If the host known module registry has an entry for /mid/, then
>     return the Module Record associated with /mid/ in the registry. 
>  3.   If /mid/ identifies a source text module, then
>      1. Assert: The source text of the module has already been fetched
>      2. Let /src/ be the source text identified by /mid/.
>      3. Let /modRec/ be ?ParseModule(/src/, /currentRealm/, /hostProvided/).
>      4. Create an entry in the host known module registry for /mid/ that
>         associates /mid/ with /modRec/.
>      5. Return /modred/
>  4.   handle other implementation specified kinds of modules

Thanks, it's useful to see that written down.


More information about the es-discuss mailing list