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 TAA03949 for caml-red; Thu, 27 Jul 2000 19:39:06 +0200 (MET DST) 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 SAA17878 for ; Wed, 26 Jul 2000 18:01:33 +0200 (MET DST) Received: from localhost.localdomain (ike73.zip.com.au [210.23.146.73]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e6QG1TD16450 for ; Wed, 26 Jul 2000 18:01:29 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id CAA15368; Thu, 27 Jul 2000 02:03:13 +1000 Message-ID: <397F0BC1.3E5DF4E3@maxtal.com.au> Date: Thu, 27 Jul 2000 02:03:13 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: andrieu@oxygene.ijm.jussieu.fr CC: caml-list@inria.fr Subject: Re: automatic construction of mli files References: <397CAB94.4B458DFB@fnac.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr Olivier Andrieu wrote: > > Julian Assange wrote: > > > > .mli files are highly redundant. Almost without exception all, or at > > the vast majority of .mli information can be generated from the > > underlying .ml implementation. We have programming languages to reduce > > redundancy, not increase it. Keeping mli and ml files in-sync is not > > only a waste of time, but error-prone and from my survey often not > > performed correctly, particularly where consistency is not enforced by > > the compiler (e.g comments describing functions and types). While > > exactly the same problem exists in a number of other > > separate-compilation language implementations, we, as camlers, should > > strive for something better. > > Urmpf. Well, it's still about type abstraction and name hiding isn't it > ? The compiler can't decide for you what you want to keep in the > interface and what should be hidden. Perhaps not, but sometimes I think it might be easier if the interface specification was consolidated with the implementation. When no .mli file is specified, ocaml generates an interface -- with all symbols becoming public -- anyhow. > But it's quite easy to generate an mli file with everything in it : > ocamlc -i -c mycode.ml > mycode.mli The problem is that subsequent refinements are lost when the implementation file is extended to include symbols: now you're committed to hand management of the .mli file. But if you stick with the generated .mli file the same interface is generated if the file is simply omitted. So the main use is to make the interface more compact by physically hiding hiden implementation details. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net