Jason, I agree with you that there needs to be making rapid progress with the dynamic module API. I also think, that TC39 need to be full engaged with the design of that API.
However, I have some issues with the specifics you defined below. My over-riding concern is that we don't loose from the specification the ability to do static, ahead-of-time module linking for implementations and situations where all modules are know and available prior to program execution. Ahead-of-time lining was an important consideration for the structuring of ES6 clause 15.2.1 and I'd hate to see us go backwards in that regard (instead I think that we should refractor ModuleDeclarationInstantiation (and Module Record) to clarify which parts of it can be performed during ahead-of-time linking). The key enabler for ahead-of-time linking is that the abstract operations and data structures required to specify module linking must not depend upon ES runtime values or runtime data structures. More specific concerns below On Aug 18, 2015, at 2:37 PM, Jason Orendorff wrote: > On Tue, Aug 18, 2015 at 12:11 PM, Domenic Denicola <d...@domenic.me> wrote: >>> HostResolveImportedModule is widely implemented by compilers, though >>> not by browsers. People are writing, using, and sharing ES6 modules today. >> >> So what is your proposal then? Just standardize the node module resolution >> algorithm, since that is what transpilers are doing? > > Here's what I had in mind: > > * Do not standardize the Node algorithm or any other module loading > algorithm in ECMA-262. That responsibility belongs to the Loader > standard. agreed > > * Change the signature of HostResolveImportedModule to match > `System.import()`, which takes a this-value and two strings (name and > referrer). HostResovleImportedModule must be an ahead-of-time friendly abstract operation, hence it can't depend upon a this-value or any runtime value. It isn't clear to me why you think that parameter is needed. Changing the refer from a Module Record to a string would not create an ahead-of-time link issue, but I'm not sure why you think that is needed. > > * Clarify that HostResolveImportedModule (and its existing callers > in the spec) operate asynchronously, e.g. by adding a > PromiseCapability argument, like PerformPromiseAll. (The async > functions proposal takes a different approach to specifying async > algorithms, but I'm not sure if that's final wording or what exactly.) The linking algorithm (which is threaded through ModuleDeclarationInstantiation, that's what I think needs refactoring) calls HostResolveImportedModule and so it can't have any dependencies upon ES promises or any other ES runtime artifacts. The easy way to make module loading asynchronous (without adding runtime dependencies or complicating linking with async steps algorithm) is to define a Job (all ES Jobs are async) that performs the module loading steps. That's essentially what TopLevelModuleEvaluationJob does. A SystemLoad job would be similar, but could have additional steps that are specific to the semantics of dynamic module loading. > > * Specify a `System` builtin object. > > * Specify a builtin method System.import(name[, referrer]) that > performs these steps: > > 1. Let promiseCapability be NewPromiseCapability(%Promise%). > > 2. Return HostResolveImportedModule(this value, name, referrer, > promiseCapability). > > Nothing terribly exciting here. Some vaguely interesting refactoring > in the second and third bullet points. I would do the equivalent via the DynamicModuleEvaluation Job: System.import (or whatever it is called)would: 1. Create a new PromiseCapability 2. Start a DynamicModuleEvaluation job, passing it the promise capability along with the user supplied arguments 3. Return the Promise object of the PromiseCapability > > The intent with `System.import()` all along was to provide a dynamic > equivalent to the static `import` syntax. Why not go one step further > and make it official that they share an implementation? That's all > this proposal does, and that's enough to make a useful standard API > for people who are writing ES6 modules right now. Fine, as long as we don't further muddle-up those parts of module linking/loading that don't have runtime dependencies with those that do. allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
