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 B71397F249 for ; Tue, 30 Oct 2012 14:33:18 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=pra; client-ip=87.98.150.177; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=mailfrom; client-ip=87.98.150.177; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mo3.mail-out.ovh.net) identity=helo; client-ip=87.98.150.177; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="postmaster@mo3.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAEPWj1BXYpaxnGdsb2JhbAAqGrEekk0BAQEBAQgLCQkUJ4IeAQEFJwsBBTYKEQsYCQQSDwkDAgECATMSEwYCAg6HYgMPBActrBWGVwOJXot3hl0DlXWBGpIY X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; d="scan'208";a="160887959" Received: from 15.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net) ([87.98.150.177]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2012 14:31:53 +0100 Received: from mail171.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 74D87FF8DA6 for ; Tue, 30 Oct 2012 14:41:54 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 30 Oct 2012 15:31:52 +0200 Received: from gwvisitors.lsv.ens-cachan.fr (HELO ?172.31.81.30?) (romain%bardou.fr@138.231.81.8) by ns0.ovh.net with SMTP; 30 Oct 2012 15:31:33 +0200 Message-ID: <508FD6B3.9080407@inria.fr> Date: Tue, 30 Oct 2012 14:31:31 +0100 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.9) Gecko/20121014 Icedove/10.0.9 MIME-Version: 1.0 To: caml-list@inria.fr X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) References: <508F22BD.7010103@riken.jp> <508F9B56.8090806@riken.jp> <508FBCDC.5000104@gmail.com> In-Reply-To: <508FBCDC.5000104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 15471272096376457760 X-Ovh-Remote: 138.231.81.8 (gwvisitors.lsv.ens-cachan.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 49 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrudekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoehrohhmrghinhdrsggrrhguohhusehinhhrihgrrdhfrheqnecuffhomhgrihhnpehinhhrihgrrdhfrhdphigrhhhoohdrtghomhenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfedu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 49 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrudekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoehrohhmrghinhdrsggrrhguohhusehinhhrihgrrdhfrheqnecuffhomhgrihhnpehinhhrihgrrdhfrhdphigrhhhoohdrtghomhenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfedu X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Re: Why should I use .mli files? Usually the code you have to duplicate is type definitions which are not private. If you don't want to copy-paste them, you can put them in a separate file, which you open in the .mli and the .ml. I often wished for this "private" or "public" keywords myself though. But it's not clear what would be the best implementation. For instance: type t = int public let f x = x + 1 What should be the type of f in the inferred interface? "int -> int" or "t -> int" or "t -> t" or "int -> t"? What about type t, should it be "type t = private int" in the interface? Or "type t"? Cheers, -- Romain Bardou Le 30/10/2012 12:41, Hongbo Zhang a écrit : > Hi all, > It's correct that .mli is great for third-party library, but it's not > helpful for in-house library and agile-development. Sometimes I have > .mli thousands of lines long, it's not fun to sync it up.... > That's why I filed a feature request which uses access modifier > 'private' like F# http://caml.inria.fr/mantis/view.php?id=5764 > If you like the proposal, plz leave a comment to support it ;-) > On 10/30/12 5:18 AM, Francois Berenger wrote: >> 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 >> >> > >