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 6398D7F249 for ; Tue, 30 Oct 2012 16:53:00 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of didier.cassirame@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of didier.cassirame@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisCAFb3j1DRVda2k2dsb2JhbABEhhirBoksAYh1CCMBAQEBCQkLCRQEI4IeAQEBAwESAg8dARsSCwEDAQsGBQQHGh0CAiIBEQEFAQoSBhMSEIdRAQMJBgudZmIJA4thT4FsgQqFCQoZJwMKWYh1AQUMkTWBEwOVdYEaihmDLhYpglCBQg X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; d="scan'208";a="160908134" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Oct 2012 16:52:59 +0100 Received: by mail-ob0-f182.google.com with SMTP id wc20so700597obb.27 for ; Tue, 30 Oct 2012 08:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xgie8bK0vg9KJcemO4eD8KrihCWurETclkxAyzykKDU=; b=MJRzLIwAhB7olRGsr0CMsJTmdWHhnX3mJsoWvZj/qR9R0JT8O68ebIKrtjfaeMqwkp LcI4ZkvjgpW8QuIKbQRmaWO+bA/9P3SdbCvSFTnjnWiIOF0Mc1R640YduI2pcA69EvoV A9IoI+UvQ7LI8CgdtDKZhWxTks6KEUSDbMPJW2TNskLaUGSYZaSt69irbprPJCtV7iYU VJM3OiK4qQ+88fsH6cRHVrCJ/WcNsw7f62PGCgLLUV/k7MxFzX0pUNJB2MqTGLvi1T5w Mw94I0E4V8uZ0e2Vdpx9y+43gPrd6wzPTabxq2RQUOvNUBYe8JHhuf2V2IY5BykNzAY5 zcKA== Received: by 10.182.202.39 with SMTP id kf7mr28129611obc.37.1351612377481; Tue, 30 Oct 2012 08:52:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.137.198 with HTTP; Tue, 30 Oct 2012 08:52:36 -0700 (PDT) In-Reply-To: <508F22BD.7010103@riken.jp> References: <508F22BD.7010103@riken.jp> From: Didier Cassirame Date: Tue, 30 Oct 2012 16:52:36 +0100 Message-ID: To: Francois Berenger Cc: caml-list Content-Type: multipart/alternative; boundary=e89a8f6471d1a243dd04cd48c74c Subject: Re: [Caml-list] Why should I use .mli files? --e89a8f6471d1a243dd04cd48c74c Content-Type: text/plain; charset=UTF-8 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 > --e89a8f6471d1a243dd04cd48c74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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=20 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=20 the .mli.
What would be the best way to handle that situation?
I=20 was thinking of making an inner module, coerce it to the desired type,=20 and open it afterwards, but the resulting module would still have a ref=20 to the inner module in its type.

E.g.:

in the file mymodule.ml

-----------------------8<---= ----------------

module Inner =3D (
struct

=C2=A0 (* imple= mentation *)

end : Sig)

open Inner

-----------------------8<-------= ------------

and the file sig.mli would be the required module type.=

didier

2012/10/30 Francois Bereng= er <berenger@riken.jp>
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 recompi= le 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 t= o create any .mli file.
I would like to know if I should bother about them.

Thanks a lot,
Francois.

--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs

--e89a8f6471d1a243dd04cd48c74c--