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 SAA04872 for caml-red; Mon, 8 Jan 2001 18:56:16 +0100 (MET) 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 PAA05977 for ; Mon, 8 Jan 2001 15:30:11 +0100 (MET) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f08EUAr26867 for ; Mon, 8 Jan 2001 15:30:10 +0100 (MET) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 05:47:42 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 8 Jan 2001 05:48:28 -0800 Message-ID: <112C6E8A1B25D34BB27D48D2FD2E96CFC9DECB@TVP-MSG-02.europe.corp.microsoft.com> From: Claudio Russo To: Xavier Leroy , Alain Frisch Cc: Caml list , sestoft@dina.kvl.dk, kfl@it.edu Subject: RE: first class modules (was: alternative module systems) Date: Mon, 8 Jan 2001 05:48:41 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) content-class: urn:content-classes:message Sender: weis@pauillac.inria.fr Hi again, > > 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. > (In OCaml and also in Luc Maranget's Hevea, I can see the need for > conditionally selecting between several structures having the same > signature; first-class modules give almost this but not quite.) Why can't you do this with first-class modules? In Moscow, you can write (note the somewhat different syntax designed to co-exist with SML): structure X as S = if toss_coin() then [structure Foo as S] else [structure Bar as S]; It's a little redundant, but works. If you want this to appear as a top-level or nested structure declaration, then this does rely on integrating open with ordinary declarations, but this is straightforward. > > As I see it, the main issue is the unification problem < S > > = < T >. > > Right. The last time we met, I asked Claudio about type inference > issues for his scheme. Basically, to "unify" and , you just > check that the module types S and T are equivalent (using the same > notion of equivalence that OCaml currently uses to for checking > compatibility between manifest module type declarations, see > the predicate > Includemod.check_modtype_equiv in the OCaml sources). > > If and contain value components with non-generalized type > variables, it is necessary to unify them along the way, and Claudio > alluded to potential traps here. However, I'm not even sure this can > happen at all in OCaml since module types cannot contain n-g type vars > and "pack" requires an explicit module type constraint. This isn't quite true (unless you don't allow n-g vars in inferred module types either). Counter-example: fun f x = [structure struct val y = x end as sig val y:int end]; > val f = fn : int -> [{val y : int}] applying the constraint should affect the type of x (which will be a free var until the signature is matched against). FYI, in Moscow you can even write, fun f (x:'a) = [structure struct val y = x end as sig val y:'a end]; > val 'a f = fn : 'a -> [{val y : 'a}] so that f is polymorphic. > > > (as a side effect, we get the local "open ... in ...") > > I'm not sure I follow you here. Did you mean that "open" and "pack" > subsume "let module ... in ..."? This I agree with. I think the best approach is the other way around, treating open as another form of declaration. Cheers, Claudio > - Xavier Leroy >