English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: first class, recursive, mixin modules (was: RE: first class m odules)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-01-12 (09:06)
From: Brian Rogoff <bpr@b...>
Subject: RE: first class, recursive, mixin modules (was: RE: first class m odules)
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 : 
                    datatype t = 
                      { data : int ; children : X.CompositeSet.t }
        structure CompositeSet : (Set.S where type elt = Composite.t) 

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

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)