From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA14202 for caml-red; Sun, 20 Aug 2000 18:52:28 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA28544 for ; Fri, 18 Aug 2000 18:36:48 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e7IGalT21662 for ; Fri, 18 Aug 2000 18:36:47 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id JAA11698; Fri, 18 Aug 2000 09:36:39 -0700 (PDT) Date: Fri, 18 Aug 2000 09:36:39 -0700 (PDT) From: Brian Rogoff To: Markus Mottl cc: OCAML Subject: Re: alternative module systems In-Reply-To: <20000814171709.A28856@miss.wu-wien.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr On Mon, 14 Aug 2000, Markus Mottl wrote: > Hello, > > having just looked at a few examples of the new module system as > implemented by Claudio Russo in Moscow ML, I wonder whether people at INRIA > have already considered it? > > It supports higher order functors, mutually recursive modules, even first > class modules. The module examples in the Moscow ML distribution also > demonstrate the new capabilites using the bootstrapping methods explained > in Okasaki's book on "Purely Functional Datastructures". This is really > neat stuff! Yes it is. I wonder what else those features will enable. In particular, the use of first class structures to configure a system at run time looks really useful to me. This is one of those things I'd normally be disposed towards doing with classes. I find it disturbing though, since my mental model of modules is that they are "second class". Also, there is the age old (in web years :) desire to have mutually recursive types which span module boundaries, and it is possible in this system. I guess there have been papers describing other solutions, but a having a real implementation is a win. > I have no idea whether there are any caveats to this solution, but it looks > pretty general. Any comments whether something similar could be implemented > in OCaml? As it seems, the solution is a true superset of the previous > module system used in SML. It's a superset of the OCaml module system too, at least that part that is comparable with SML (obviously SML doesn't have classes and such). -- Brian