Module naming and declarations

Claus Reinke claus.reinke at
Thu Apr 25 16:08:50 PDT 2013

> Module names play a role in three processes, in general:
> 1. As a way to identify local components.
> 2. As a way to find the physical resource that is the source code (or
> object code) of the module.
> 3. As a way for two separately developed components to coordinate
> about which module they mean.
> In the current design, the internal names (eg, "jquery") serve role 1,
> and URLs (as generated by the loader hooks) serve role 2. The
> coordination role is played by internal names in a shared registry.

You argue for a two-level system of non-lexical names to support
configuration - okay. But why does that imply you have to drop
the lexical naming altogether, instead of using a three-level system
(from external to internal to lexical names)?

Also, in a two-level system of external and lexical names, could one
not model the coordination level by a registry/configuration module?

// using loose syntax
module registry {
module jquery = <external remote or local path>
export jquery

module client {
import {jquery: $} from registry


More information about the es-discuss mailing list