ModuleDeclarationInstantiation behaviour after failure

[Allen Wirfs-Brock]

> On Jul 14, 2016, at 3:51 AM, Jon Coppeard <jcoppeard at mozilla.com <mailto:jcoppeard at mozilla.com>> wrote:
> 
> On 07/07/2016 22:33, Allen Wirfs-Brock wrote:
>> I would expect implementations to
>> discard any module records it created during a linking phase that throws
>> errors.
> 
> I think it's not trivial to know which module records to discard.
> 
> Thinking out loud:
> 
> A module loader may be simultaneously loading multiple top-level modules
> which have overlapping dependency graphs.  So an imported module may be
> created to satisfy the dependencies of more than one top-level module
> that is currently being loaded.

In the spec, module instantiation is always initiated by a TopLevelModuleEvaluationJob. Such jobs are serially executed to completion.  The spec. explicitly says that an implementation may pre-instantiate and link modules ( it could even happen during a build process) as long as error reporting is deferred to the actual TopLevelModuleEvaluationJob (of course a build time linker would also report build time errors).

So, form the spec perspective there is no semantics of “simultaneously loading” multiple top-level modules.  To conform to those semantics, an implementation that wants to simultaneously eagerly instantiate and link modules has to do it in a manner that preserves the serial instantiation semantics.


> 
> We can't throw away all dependencies on failure because that could
> discard successfully loaded modules that are in use by a previously
> loaded module.  A subsequent load of another module could then re-load a
> different version of these modules.
> 
> Really we only need to throw away the module which failed to link and
> every ancestor module up to the root of the tree, i.e. those for which
> instantiation has started but did not complete.  But a module loader
> doesn't have a way to work this out.
> 
> One solution might be to have the loader maintain an 'instantiated' flag
> for each module which is initially false and to set this for all
> uninstantiated descendants on successful instantiation.  Then we could
> throw away uninstantiated descendants on failure.  (This would discard
> more than necessary, but that doesn't matter).
> 
> Does that make sense?  I think this would work but it feels like it's
> making the loader do extra work to compute state that could more simply
> be stored in the module record itself.

I’m just thinking out load too,  But here is how I would approach it.

Module Records are created by ParseModule (often indirectly via HostResolveImportedModule) and subsequently retrieved by HostResolveImportModule. 

I would treat steps 3-5 of [TopLevelModuleEvaluationJob](https://tc39.github.io/ecma262/#sec-toplevelmoduleevaluationjob <https://tc39.github.io/ecma262/#sec-toplevelmoduleevaluationjob>) as an atomic transaction that either succeeds or fails.  During such a transaction, any new module record that is created is considered a “pending module record”. When a transition successfully completes, all of its pending module records permanently become “committed module records” but if a transaction fails its pending module records are discarded.  During a transaction, HostResoveImportedModule uses both the committed and pending module record sets to resolve import requests.  

Regarding storing state (for example, committed or pending) in module records:  Module records (like most data structures in the spec) are just abstrations used by the specification to describe the semantics and observable state changes.  An implementation is free to represent those abstractions any way it wants and certainly can incorporate additional unobservable implementation state.

Allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160714/2b6bcd22/attachment.html>