ModuleDeclarationInstantiation behaviour after failure

[Jason Orendorff]

On Thu, Jul 7, 2016 at 12:09 PM, Caridy Patiño <caridy at gmail.com> wrote:

> Moving step 7 to the end is not an option since the primary use of that
> step is to support circular references.
>

Not sure this is helpful, but back when I was working with Dave on this
stuff, it was supposed to work something like this:

* The loader determines when a set of new modules is ready to link. This
only happens after resolving all requested modules for the whole set.

* Check that all requested modules actually have the export bindings we
require of them. If not, it's an error.

* Linking. We create module Environments and all their bindings, including
import bindings. Observably, this is an atomic step and it can't fail. We
already checked for all possible link errors.

* Next, we evaluate module bodies, etc.

So in our design, if code ran in a module environment, that environment was
fully linked. It looks like ModuleDeclarationInstantiation does not have
this guarantee. If true, that's a serious bug.

> As for recovering from errors, this is in the realm of the loader and the
registry to prevent subsequence attempts to instantiate a source text
module record that failed already. [...]

It's fine to have an error sometimes shoot down a whole graph of modules.
The problem here is that the failed Environments can be exposed later. The
spec says you're even supposed to run code in them, right? But forging
ahead with partially-initialized data structures seems as obviously
undesirable in a spec as in running code -- that's begging for bugs -- and
it's an unreasonable implementation burden too.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160707/be7afb91/attachment.html>