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 BAA05893; Wed, 1 May 2002 01:57:46 +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 BAA05889 for ; Wed, 1 May 2002 01:57:45 +0200 (MET DST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g3UNvg528326; Wed, 1 May 2002 01:57:43 +0200 (MET DST) Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g3UNvaXt007808; Wed, 1 May 2002 09:57:37 +1000 (EST) Received: from ozemail.com.au (ppp81.dyn146.pacific.net.au [210.23.146.81]) by wisma.pacific.net.au with ESMTP id JAA12130; Wed, 1 May 2002 09:57:31 +1000 (EST) Message-ID: <3CCF2F6B.9000504@ozemail.com.au> Date: Wed, 01 May 2002 09:57:31 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Gregory Morrisett CC: Francois.Pottier@inria.fr, caml-list@inria.fr Subject: Re: [Caml-list] Modules and typing References: <706871B20764CD449DB0E8E3D81C4D4301EE6D2B@opus.cs.cornell.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Gregory Morrisett wrote: > >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. > Ocaml object system does this. Very confusing it is too, seeing the private data in the interface .. but it is a good system, because it is possible to abstract that data away by a further abstraction. A large class of clients can work solely with the abstraction .. not all because of the covariance problem .. and those that can don't need recompilation when the representation changes. The biggest pain in this model is that one has to cut and paste a lot during development... and also the lack of inter-recursion between classes and type means you have to encode the abstraction as a parameterised class type and then instantiate it within the type recursion. But the beauty of it is that at the cost of one pointer (to the object) the abstraction allows intermodule recursion.. the order of class compilation is irrelevant provided only that the abstractions are introduced first. -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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