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 PAA26554; Tue, 30 Apr 2002 15:44:13 +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 PAA26549 for ; Tue, 30 Apr 2002 15:44:13 +0200 (MET DST) Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g3UDiB510379; Tue, 30 Apr 2002 15:44:12 +0200 (MET DST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] Modules and typing Date: Tue, 30 Apr 2002 09:44:10 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301EE6D2B@opus.cs.cornell.edu> Thread-Topic: [Caml-list] Modules and typing Thread-Index: AcHwPdk9cEgM016eT/uodT7yRMSwOQADf2aw From: "Gregory Morrisett" To: , "John Max Skaller" Cc: Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > + require that abstract types are pointer types, as in=20 > 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=20 closely to what Modula-3 provides with it's notion of "ref" types. =20 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 =3D int] The client is type-checked with t treated abstractly, but the=20 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 ------------------- 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