March 29 meeting notes

Claus Reinke claus.reinke at
Sat Mar 31 01:29:31 PDT 2012

>>> DaveH's presentation about module loaders
>> Shouldn't any newly designed async loading APIs support promises?
> No, for the very simple reason that promises have not been standardized
> and won't be in ES6.

Understood. Though this leaves us with:

- use of module loaders could profit from promises (eg, importing several
    modules in parallel, waiting for all of them to be available, or mixing
    module with other promise-based dependencies)

- promises are in wide-spread use, are not standardized in ES, and do not
    seem to converge on a single implementation/API; as long as ES specs
    couldn't profit from promises, that was not as much of a problem

For the special case of modules, one could add off-spec support for a
currently popular promise library, to avoid further divergence.

> It Just Works. :) JS is a multi-staged language. One stage can modify
> the module table, and then later scripts will be compiled in the context
> of that new module table. The module itself is immutable.

So, a set only influences later dynamic loads? And the latest set before
load wins? And, since "static" import is synchronous (same stage), any
"static" construct textually after the set, but in the same stage, refer to
the old module table, while the set-effect is implicitly pending?

Is the multi-stage aspect spelled out somewhere? In particular, I
would have expected to be able to use "static" module constructs
in module loader callbacks:

// stage n
System.load("m", m =>    // "static" checks for stage n+1 at load-time
    import {f,g} from m;        // stage n+1

but ImportDeclaration seems limited to Program and ModuleBody.

>> Wouldn't it be more honest to use conditional
>> loading, falling back to dynamic module handling?
> You can certainly do that too. But the idea of polyfills is that client
> code (including third-party libraries you may be using that you don't
> want to or can't change) should be able to be written to recent
> versions of a standard API, and the polyfill makes sure to back-fill
> any gaps in older environments.

I keep forgetting that parameterized modules are not yet on the
table. If imports were module parameters, one could pass in patched
imports to unchanged importers, without having to assign to the
module table (fewer side-effects).

>>> Module syntax alternatives:
>>> module x at "foo.js"
>>> module x = "foo.js"
>>> module "foo.js" as x
>>> module x at "foo.js"
>> module x from "foo.js"
> As I've said before, this uses "from" inconsistently -- it muddles the
> difference between binding a name to an external module (module
> x from "foo.js") and binding a name to a specific export of an external
> module (import x from "foo.js").

"from" on its own doesn't do much, it is a modifier; "module" and
"import" are the operative words. "module x from source" indicates a
non-inline module, to be fetched from source, "import x from module"
indicates a non-inline declaration, imported from module.

Since module declarations are just declarations, one might also consider
'import m from "foo.js"', but that wouldn't make a syntactical distinction
for non-inline module declarations.


More information about the es-discuss mailing list