On Thu, Jul 7, 2016 at 12:09 PM, Caridy Patiño <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
