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 3590F7F24A for ; Tue, 30 Oct 2012 16:57:11 +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=188.165.43.173; 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=188.165.43.173; 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=188.165.43.173; 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: AsYAAHT4j1C8pSutmWdsb2JhbABEhhirBpJNAQEBAQEICwsHFCeCHwEFIw8BBTYKEQsaAgUEEggDAgIJAwIBAgEzARETBgICDodiAw8EB6ozgjuGXQOJXoEgileDOYIRgRMDlXWBGpIY X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; d="scan'208";a="160908599" Received: from 6.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net) ([188.165.43.173]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2012 16:56:37 +0100 Received: from mail171.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id B6816FF8E4F for ; Tue, 30 Oct 2012 17:06:37 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 30 Oct 2012 17:56:35 +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 17:56:34 +0200 Message-ID: <508FF8B2.8080209@inria.fr> Date: Tue, 30 Oct 2012 16:56:34 +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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 17920385869205506592 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: gggruggvucftvghtrhhoucdtuddrfeehfedrudelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoehrohhmrghinhdrsggrrhguohhusehinhhrihgrrdhfrheqnecuffhomhgrihhnpehmhihmohguuhhlvgdrmhhlpdhinhhrihgrrdhfrhdphigrhhhoohdrtghomhenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfeej X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 49 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrudelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoehrohhmrghinhdrsggrrhguohhusehinhhrihgrrdhfrheqnecuffhomhgrihhnpehmhihmohguuhhlvgdrmhhlpdhinhhrihgrrdhfrhdphigrhhhoohdrtghomhenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfeej X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Why should I use .mli files? Maybe you can just write "include module type of X" where X is the module which already has the .mli. Or you define the signature as a module type Sig in a separate file "x.ml" and write "include X.Sig". Cheers, -- Romain Bardou Le 30/10/2012 16:52, Didier Cassirame a écrit : > > Thinking about it, there's at least one case where mli files are not so > useful: When you have several modules which must all comply with a > certain module type. In that case, all the mli files would be identical, > and a modification of the module type would necessitate to change all > the .mli. > What would be the best way to handle that situation? > I was thinking of making an inner module, coerce it to the desired type, > and open it afterwards, but the resulting module would still have a ref > to the inner module in its type. > > E.g.: > > in the file mymodule.ml > > -----------------------8<------------------- > > module Inner = ( > struct > > (* implementation *) > > end : Sig) > > open Inner > > -----------------------8<------------------- > > and the file sig.mli would be the required module type. > > didier > > 2012/10/30 Francois Berenger > > > 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 > > >