Modules: compile time linking (was Re: Modules feedback, proposal)
claus.reinke at talk21.com
Sun Apr 1 07:52:34 PDT 2012
> If you have dynamic modules, you can't use them to export any
> compile-time constructs, like macros, static operator overloading,
> custom literals, or static types. If you load a module at runtime,
> then it's too late by the time you actually have the module to use
> it for anything at compile time.
That is not quite accurate, unless I'm misinterpreting you. See, for
instance, the variety of work surrounding type Dynamic in ML-like
languages: it is possible to define language constructs that represent
the static/dynamic phase distinction, so that
- toDynamic(expression) pairs an expression with a runtime
representation of statically inferred information (such as type)
- fromDynamic([info,expr]) extracts an expression from such a
pair *if and only if* the runtime info for expr matches the
statically inferred information for the usage context (since
this can fail, it is often embedded into pattern matching, aka
toDynamic marks program points where objects pass out of
range of static inference (eg, storing modules/objects to disk),
fromDynamic marks program points where dynamically
annotated objects need to be checked against static information
before embedding them (such as linking a dynamically loaded
This pair of constructs allows for multiple program stages,
each with their own static/dynamic phases. You can load a
module at runtime, then enter compile time for that module,
then enter a new runtime stage with the newly compiled and
linked code. This was used, eg, in orthogonally persistent
programming languages to dynamically store/load statically
typed code/modules to/from database-like storage.
Multi-stage languages drive this further by allowing stage-n
dynamic constructs to set static properties for stage-(>n) code.
Their motivation tends to be meta-programming.
Which is why I'm confused by the staging aspects of ES6 modules:
- ES is a multi-stage language, thanks to eval and module load
- ES6 modules offer "static" constructs only for the first stage,
after which everything seems to devolve to dynamic again?
I'm not saying this is wrong, since JS analysis is hard, but it
would be good to be clear about whether this single-stage
approach to a multi-stage problem is intended, or whether
the current spec incompletely captures the intentions.
More information about the es-discuss