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 OAA04554; Thu, 2 May 2002 14:31:10 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 OAA04543 for ; Thu, 2 May 2002 14:31:09 +0200 (MET DST) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g42CV8D21972 for ; Thu, 2 May 2002 14:31:08 +0200 (MET DST) Received: (qmail 12839 invoked by uid 0); 2 May 2002 12:31:06 -0000 Date: Thu, 2 May 2002 14:31:07 +0200 (MEST) From: Benedikt Grundmann To: "Gregory Morrisett" Cc: Francois.Pottier@inria.fr, skaller@ozemail.com.au, caml-list@inria.fr MIME-Version: 1.0 References: <706871B20764CD449DB0E8E3D81C4D4301EE6D2B@opus.cs.cornell.edu> Subject: RE: [Caml-list] Modules and typing X-Priority: 3 (Normal) X-Authenticated-Sender: #0009085902@gmx.net X-Authenticated-IP: [80.129.67.49] Message-ID: <22013.1020342667@www9.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > + require that abstract types are pointer types, as in > > Modula-3 (?) and, more > > recently, Cyclone > > Actually, Cyclone has two different kinds of abstract types: > One abstracts pointer types (really, types that are compatible > with void*) and another kind that abstracts any type. The latter > kind can only be used under a pointer. I think this corresponds more > closely to what Modula-3 provides with it's notion of "ref" > types. > > There's another option that you didn't mention which is the approach > taken by Ada: Have a notion of "private" types in interfaces, e.g. > > type t > [private t = int] > > The client is type-checked with t treated abstractly, but the > compiler can then specialize the client knowing what the implementation > of t is. Of course, by leaking this information into the interface, > you're effectively losing separate compilation in the sense that > if the implementation of t changes, then its interface must also > change and all clients must then be (potentially) re-compiled. But > this is a simple option which avoids some of the complexity that > you run into if you try to use abstract kinds to classify types > according to implementation details that a compiler might need > (e.g., size, calling-convention, and alignment constraints.) > > -Greg Another option related to this is to generate a compiler only interface file (maybe even binary). Which contains everything the compiler needs to know about the implementation of an interface. Everything mentioned above applies to this solution too, with the added benefit that a reader of the interface can't make stupid assumptions about the implementation which might not be true in the next release :-) Bene -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners