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 MAA07731 for caml-red; Mon, 8 Jan 2001 12:29:51 +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 LAA02627 for ; Mon, 8 Jan 2001 11:42:08 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f08Ag3D24524; Mon, 8 Jan 2001 11:42:03 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA26380; Mon, 8 Jan 2001 11:42:03 +0100 (MET) Date: Mon, 8 Jan 2001 11:42:03 +0100 From: Xavier Leroy To: Alain Frisch Cc: Caml list Subject: Re: first class modules (was: alternative module systems) Message-ID: <20010108114203.E13356@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from frisch@clipper.ens.fr on Sun, Jan 07, 2001 at 01:20:42AM +0100 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. (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.) > 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. > (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. - Xavier Leroy