From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA02703; Thu, 22 Mar 2001 01:23:26 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 BAA02745 for ; Thu, 22 Mar 2001 01:23:25 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f2M0NNj23536; Thu, 22 Mar 2001 01:23:23 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f2M0NMo01130; Wed, 21 Mar 2001 19:23:22 -0500 (EST) (envelope-from patrick@watson.org) Date: Wed, 21 Mar 2001 19:23:22 -0500 (EST) From: Patrick M Doane To: Xavier Leroy cc: Chris Hecker , caml-list@inria.fr Subject: Re: [Caml-list] recursive modules redux, & interface files In-Reply-To: <20010321194138.A29405@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi Xavier, Your example demonstrates that a proposal for such an extension should be more explicit about how it should work. I had a particular implementation in mind from my post yesterday: For every module definition M that has a signature S For every type definition t in S that contains optional type-information and is not defined in M Add the type definition of t to M (preserving the order from S) Proceed with the usual algorithms for type checking, matching structures, etc. I think this should work properly. Anything I might have missed? You seem to elude to special cases that are not immediately obvious. I agree that it becomes kludgy to remove the separation that currently exists between structures and signatures. However, as a programmer maintaining the duplicate types also seems kludgy . After all, the compiler has the information available, why doesn't it use it? This seems to be a case where a compromise between theory and practice should be explored. Patrick On Wed, 21 Mar 2001, Xavier Leroy wrote: > It becomes practically inconvenient when the signature is known at the > time of the structure definition: > > module M : sig type t = A | B ... end = > struct type t = A | B ... end > > Which is the case with interface and implementation files. > > In this case, one could envision an automatic completion of the > structure / implementation file so that concrete type specifications > from the signature do not need to be implemented in the structure. > Doing this right is not obvious, though. First, it's not enough to > say that a concrete type spec does not need to be matched in the > structure. This would type-check > > module M : sig type t = A | B end = struct end > > but not > > module M : sig type t = A | B val v : t end = struct let v = A end > > In other terms, the unmatched concrete type specs in the signature > need to be somehow reintroduced in the structure definition, so that > other parts of the structure may refer to them. While I think it can > be done in most practical cases, it's a bit of a kludge and I'm not > sure how to do this in all cases. > > Is the practical value of this kludge enough to forget that it's a > kludge? Can't we live with the current duplication of concrete type > definitions in the name of systematic, principled module systems? > I really don't know. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr