Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
RE: first class modules (was: alternative module systems)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-01-10 (18:51)
From: Claudio Russo <crusso@m...>
Subject: RE: first class modules (was: alternative module systems)

> > > a few month ago, Markus Mottl pointed to this mailing 
> list the work by
> > > Claudio Russo on first class modules. There were no 
> answer about plans to
> > > implement such a system for OCaml.
> > 
> > Well, it seems like Russo's first-class modules could be added with
> > relatively little effort, if there is a sufficient need for them.
> Does this include the recursive modules aspect of Moscow ML 
> too? That's
> where I feel the shoe pinching. I realize that at least one 
> big name in
> the ML community dislikes the notion and admittedly my main 
> issue could be 
> resolved by a recursion between a type definition and a 
> module but it can
> also be fixed with recursive modules. The problems arise 
> fairly frequently.

The discussion is about first-class modules only, I think. Recursive
modules are
a completely separate issue. You can support either without the other.
Although Moscow supports recursive structures, their status is
but I thought adding something simple was better than nothing at all. 
Recursive functors should be an easy generalisation of recursive
I didn't put them in because I couldn't find any nice examples (but I
didn't look very hard either).

> Do the implementors have any impressions as to whether the 
> Moscow ML approach or
> the "mixin module" approach discussed here will be used to 
> address this
> problem? 

Has the mixin module stuff been formalised enough for actual
implementation? 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). (BTW, the distribution has a minor bug but this
is fixed for the next release.)


> -- Brian