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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 1CD107F24A for ; Tue, 30 Oct 2012 11:01:22 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.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=mail1-smtp-roc.national.inria.fr; envelope-from="mmatalka@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: AqsBAMukj1DRVda2kGdsb2JhbABEsR6JKgGIZAgjAQEBAQkJDQcUBCOCHgEBAQMBEgIsARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEhCHUQEDCQYLnRxiCQOMMIFsgQqEcwoZJwMKWYh1AQUMi2mGXQOVdIEajUcWKYJQgUI X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; d="scan'208";a="179501738" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Oct 2012 11:01:21 +0100 Received: by mail-ob0-f182.google.com with SMTP id wc20so116963obb.27 for ; Tue, 30 Oct 2012 03:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w52VC6xrK93LsX3Beu3kvacD3NgAQjL3SmArclLa3i4=; b=UP5M/8DDZwAsiLozT9/QCPuWRrsYrK7T7+ZeAFqUYVDN782JmodB8U85fUqDo4hMWc o/6idnptYwlNC/C+BhwkZmge6HKxZGmr0/N1pLQCLRKGgF9FBwe7zbaXYtSDmnfrx87e rUF+ilY6QFqjnC2PzwcwnMbhZtCeN+vV1yD+Z5Oq9aEsPbOvm2T8Ku9fkM0vHDNydy1W gPyfHtYiOJYlrWDhIA61TaV7yhNI8GTnWz4ikOPKtwOxCVJ/SUSajiR/YztMU+6aVhx4 ihmPF5UbRWRfPjqOjhbJSz+6jlM8xAa73sqDkaiRx/eR2CN5R5UMBRuzjpGO2YlwmwNZ 19Qg== MIME-Version: 1.0 Received: by 10.60.14.6 with SMTP id l6mr28189113oec.87.1351591279999; Tue, 30 Oct 2012 03:01:19 -0700 (PDT) Received: by 10.76.79.132 with HTTP; Tue, 30 Oct 2012 03:01:19 -0700 (PDT) Received: by 10.76.79.132 with HTTP; Tue, 30 Oct 2012 03:01:19 -0700 (PDT) In-Reply-To: <508F9B56.8090806@riken.jp> References: <508F22BD.7010103@riken.jp> <508F9B56.8090806@riken.jp> Date: Tue, 30 Oct 2012 11:01:19 +0100 Message-ID: From: Malcolm Matalka To: Francois Berenger Cc: caml-list , Anton Lavrik Content-Type: multipart/alternative; boundary=e89a8fb201122039a704cd43de14 Subject: Re: [Caml-list] Why should I use .mli files? --e89a8fb201122039a704cd43de14 Content-Type: text/plain; charset=ISO-8859-1 Ocamlc can produce mli files for you, but I generally write the mli first anyways. I found the repetition annoying at first but I quickly found it to be a none issue and has saved me a few times. Especially when type system infers a different type than I thought, the error is localized to the module. On Oct 30, 2012 10: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 >>> >> > > -- > 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 > --e89a8fb201122039a704cd43de14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ocamlc can produce mli files for you, but I generally write the mli firs= t anyways. I found the repetition annoying at first but I quickly found it = to be a none issue and has saved me a few times. Especially when type syste= m infers a different type than I thought,=A0 the error is localized to the = module.=A0

On Oct 30, 2012 10:18 AM, "Francois Berenge= r" <berenger@riken.jp> = 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 OCam= l
user, but hey, at least you are not alone :)

I'm surprised by some of the comments you've received. The fact tha= t
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<= br> 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 : =A0typexpr" 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 <berenger@riken.jp> 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 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. =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


--
Caml-list mailing list. =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
--e89a8fb201122039a704cd43de14--