ModuleDeclarationInstantiation behaviour after failure

[Jon Coppeard]

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.

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.

Jon