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 XAA21253 for caml-red; Tue, 25 Jul 2000 23:57:05 +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 DAA04697 for ; Tue, 25 Jul 2000 03:14:10 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e6P1E8j20365 for ; Tue, 25 Jul 2000 03:14:09 +0200 (MET DST) Received: from localhost (sansho.kurims.kyoto-u.ac.jp [130.54.16.90]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA26122; Tue, 25 Jul 2000 10:14:10 +0900 (JST) To: proff@iq.org Cc: caml-list@inria.fr Subject: Re: automatic construction of mli files In-Reply-To: Your message of "24 Jul 2000 15:34:22 +1000" References: X-Mailer: Mew version 1.93 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000725101321D.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 25 Jul 2000 10:13:21 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Sender: weis@pauillac.inria.fr From: Julian Assange > .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. I know the argument against .h files. However I'm not sure it applies to .mli, which in my view have a role rather different of C headers. One first point is that they are optional. If you don't like the burden of writing them (which is much simplified by the -i option of the compiler), you can just avoid them. A tool like ocamlbrowser still allows you to browse the contents of the .cmi file, thus giving access to all type information. The only capacity you loose is export control, but in many cases this doesn't really matter anyway. So why do people write .mli files ? Just because it is nice to cleanly separate interface and implementation. This goes completely against some ideas in the OO community, particularly concerned by the close relationship between specification and implementation, but thanks to a more powerful type system, a larger part of the specification is verifiable. A verifiable redundancy can be profitable, in fact all the ML type system is about getting enough redundancy to your code to detect errors. Not to say that the current situation is perfect. The fact you have to duplicate all type definitions is not so nice for instance. But for people used to the .ml/.mli dichotomy, having both kind of information united in a single file does not seem very attractive. Practically what I usally do when I start a new project in Caml is start without .mli files, until my project gets structured enough so that I know what needs to be exported from each module. Then I generate .mli's with the -i option of the compiler, trim definitions to keep only the ones I need, and eventually add comments to definitions (I'm often happy enough with labels only, but I know it's not Good). From there on changes to the .mli are small enough, and actually I want to know when the interface is changed, since this may influence other modules. Regards, --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG