My "litmus test" for recursive modules is that it fixes the well known
problem with expressing what OO folk call the Composite pattern,
essentially a recursively defined collection type with a leaf/node
relationship. Here is an approxmation of what I want to do in "faux-Mosml
with OCaml libraries". Forgive my errors, I don't use SML. The idea
should be clear. 

signature COMPOSITE = 
    rec(X : sig structure CompositeSet : sig type t end end) 
    sig structure Composite : 
                  sig 
                    datatype t = 
                      { data : int ; children : X.CompositeSet.t }
                  end
        structure CompositeSet : (Set.S where type elt = Composite.t) 
    end;

structure T = rec(X : COMPOSITE) 
  struct 
	structure Composite = 
          struct 
            datatype t = { data : int ; children : X.CompositeSet.t }
          end
        structure Ord : Set.OrderedType = 
          struct 
            type t = Composite.t 
            let compare = Pervasives.compare
          end
	structure CompositeSet = Set.Make(Ord)  
    end

This is syntactically heavy, but better than the parameterization trick 
needed now, and I'd be satisfied. I do need to do that functor
instantiation, so if you can't do it in Mosml it needs to be added. 

I agree that the first-class module extension is useful on its own too,
but in my own programming the problem I mention above arises frequently
enough that I consider this a flaw of (current) ML style modules. Every 
language has flaws but since OCaml is so close to perfection every flaw 
seems large ;-). 

-- Brian

 On Thu, 11 Jan 2001, Dave Berry wrote:

> We ran into an example (in SML) during the development of MLWorks.  I can
> only remember it vaguely, but there were two large module hierarchies.
> These hierarchies were in logically different parts of the system.  A new
> development built on top of these hierarchies meant that we needed to make
> one element from the bottom of each hierarchy be mutually recursive with
> each other.  I suspect that since we were using a fully functorised style,
> what we wanted to do was to make two functors mutually recursive.  In
> practice we had to combine the module hierarchies to make the types and
> values mutually recursive at the bottom of the new hierarchy.
> 
> I wish I could remember what the example was, because it was a clear case
> where the ML module system was too inflexible to meet the pragmatic needs.
> Imagine how we would have been stuck if the two module hierarchies were
> libraries from different suppliers, especially if they were only distributed
> in compiled form.
> 
> Dave. 
>   
> 
> -----Original Message-----
> From: Claudio Russo [mailto:crusso@microsoft.com]
> Sent: Thursday, January 11, 2001 10:33
> To: Alain Frisch
> Cc: Brian Rogoff; Caml list
> Subject: RE: first class, recursive, mixin modules (was: RE: first class
> modules)
> 
> 
>