From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 015D37F249 for ; Tue, 30 Oct 2012 10:18:22 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.162; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.162 as permitted sender) identity=mailfrom; client-ip=134.160.33.162; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.162 as permitted sender) identity=helo; client-ip=134.160.33.162; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAPGZj1CGoCGimWdsb2JhbABEsR6SOgEBAQEBCAsLBxQngh4BAQQBODYKAQULCw4KCQQSDwkDAgECATMSBg0BBQIBAQ6HYgMJBgusHYZBA4lei3WGXQOIV40dgRqET41X X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; d="scan'208";a="160854717" Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2012 10:18:20 +0100 Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 661991260302; Tue, 30 Oct 2012 18:18:17 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id BEEE21270063; Tue, 30 Oct 2012 18:18:14 +0900 (JST) Message-ID: <508F9B56.8090806@riken.jp> Date: Tue, 30 Oct 2012 18:18:14 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anton Lavrik CC: caml-list References: <508F22BD.7010103@riken.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.30.90323 Subject: Re: [Caml-list] Why should I use .mli files? On 10/30/2012 03:12 PM, Anton Lavrik wrote: > Hi Francois, > > I don't use .mli files that much. Granted, I'm a rather casual OCaml > user, but hey, at least you are not alone :) > > I'm surprised by some of the comments you've received. The fact that > some people tend to practice top-down coding more than others doesn't > really mean anything. Other people do it differently even regardless > of the language they use. For me, paper and pencil are far more useful > than .mli files up until the interfaces converge and stabilize. > > In general, .mli files are useful and even essential for libraries and > large projects. For instance, they allow to clearly (and cleanly) > define interfaces and help with separate compilation (i.e. to avoid > recompiling parts). > > The biggest inconvenience with .mli files as I see it is that I have > to repeat myself and make related but slightly different changes in > two places when I change a module implementation. I would very much > prefer to declare and document public interfaces next to the > implementation and have language tooling take care of separate > compilation and documentation generation. Thanks for pointing this out! The exact thing that would annoy me if I would adopt .mli files: repeating myself. In C, I used a tool call cproto to extract header files out of my .c implementation code. Then, I just snipped out some parts of the header I didn't want to make public, if I remember well. That was not perfect, but at least I did not have to maintain two files at the same time. > OCaml is kind of clumsy in this respect. For example, it does allow to > specify types for values and function parameters inline. The syntax > isn't the best, but the feature itself is very useful and I rely on it > all the time. But when I get to define a type signature for a function > e.g. in .mli file, I loose the ability to use parameter names and have > to specify them in the comments. > > Overall, I count .mli files as a fairly minor language usability > issue. Perhaps, it wouldn't be even very hard to fix, for example, by > allowing something like "[public] val value-name : typexpr" in .ml > files so that .mli/.cmi files can be generated automatically with > desired public interfaces. I was thinking more about "export" as the keyword of choice, but the functionality would be exactly the same. Best regards, Francois. > Anton > > > On Mon, Oct 29, 2012 at 7:43 PM, Francois Berenger wrote: >> Hello, >> >> Here is my stupid question of the day: >> what's the use of those .mli files? >> >> Is it just to separate interface from implementation >> so that the implementation of a module can be changed >> without clients of its interface to have to bother? >> >> Does it make compilation of large software faster >> by allowing for more parallelization and maybe later on avoiding to >> recompile some parts? >> >> Usually I program in a pure functional style, so my modules >> don't carry an internal state. >> I feel like "if someone want to re-use a function, so be it". >> If I really want to hide a function that I am afraid people >> may call in an incorrect manner, I declare it internally >> to some public function and use it correctly. >> >> Also, maybe I only work on toy-size OCaml projects. So, I never bothrered to >> create any .mli file. >> I would like to know if I should bother about them. >> >> Thanks a lot, >> Francois. >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs