first class, recursive, mixin modules (was: RE: first class modules)

[Alain Frisch <frisch@clipper.ens.fr>]

On Wed, 10 Jan 2001, Claudio Russo wrote:

> Moscow's recursive modules have the advantage that they
> leverage many of the concepts already existing in the Definition. If I
> recall correctly, they require one new kind of semantic object, a simple
> generalisation of enrichment, and two new syntactic constructs with
> associated evaluation and typing rules. Current main drawbacks: heavy
> syntax requiring forward declarations,
>  no support for cross-compilation-unit recursion and recursion on module
> terms requires a dynamic check for each
> forward reference (this is because the implementation imposes no
> restriction on whether the recursion is safe or not, forcing a dynamic
> check for definedness).

Are there real examples using recursive modules with these restrictions ?

You can always define everything outside the structures (or in the first
one), then copy the types and values in the structures. Of course, you
loose the modularity of definitions, but with recursive modules as in
MosML, you loose the static typing for the module language (Bind
exceptions) and also the modularity (different source files;
separate compilation). 

If you accept runtime checks, the solution adopted
in the OCaml compiler to break the circle of dependencies between
the Core and Module type checkers (forward declaration with a reference
updated when the definition is available) has the advantage of retaining
separate compilation.


Back to first class packaged modules: a very useful feature for runtime
configuration of applications would be the possibility to load the
packages from the disk/network (that is, dynamic loading; the
signature of trusted packages can be checked as in the Dynlink module).


About mixins: what is the proposed dynamic semantic ?  I guess the
evaluation of the mixins, which can have side effects or depend on the
environment, is done when then composition yields a fully defined
structure. But this operation involves a reordering of the definitions,
so it may be non trivial to predict the evaluation order of the different
fields. Is there a requirement for the ordering to be compatible when
possible with the order of definition for values/submodule in each mixin
of the composition ?


-- 
  Alain Frisch