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 TAA09080 for caml-red; Wed, 10 Jan 2001 19:51:05 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA02244 for ; Wed, 10 Jan 2001 12:41:50 +0100 (MET) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f0ABfm510782 for ; Wed, 10 Jan 2001 12:41:49 +0100 (MET) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 10 Jan 2001 02:32:53 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 10 Jan 2001 02:32:50 -0800 Message-ID: <112C6E8A1B25D34BB27D48D2FD2E96CFC9DED1@TVP-MSG-02.europe.corp.microsoft.com> From: Claudio Russo To: Brian Rogoff , Xavier Leroy Cc: Alain Frisch , Caml list Subject: RE: first class modules (was: alternative module systems) Date: Wed, 10 Jan 2001 02:32:43 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) content-class: urn:content-classes:message Sender: weis@pauillac.inria.fr > > > 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 "experimental", but I thought adding something simple was better than nothing at all. Recursive functors should be an easy generalisation of recursive structures; 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.) Cheers, Claudio > -- Brian > >