From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <daniel.buenzli@erratique.ch>
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 7588D7F249
	for <caml-list@sympa.inria.fr>; Wed, 31 Oct 2012 02:44:11 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  daniel.buenzli@erratique.ch) identity=pra;
  client-ip=74.55.86.74;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="daniel.buenzli@erratique.ch";
  x-sender="daniel.buenzli@erratique.ch";
  x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  daniel.buenzli@erratique.ch) identity=mailfrom;
  client-ip=74.55.86.74;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="daniel.buenzli@erratique.ch";
  x-sender="daniel.buenzli@erratique.ch";
  x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@smtp.webfaction.com) identity=helo;
  client-ip=74.55.86.74;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="daniel.buenzli@erratique.ch";
  x-sender="postmaster@smtp.webfaction.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjIBAPuBkFBKN1ZKnGdsb2JhbABEwCODfgEBAQEBCAsJCRQngh4BAQQBMgEFQAEFCwsYCRMBAg8JAwIBAgErGgYOiAUGBK49jg2Ld4Y7A5tLjU4O
X-IronPort-AV: E=Sophos;i="4.80,683,1344204000"; 
   d="scan'208";a="179611673"
Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Oct 2012 02:44:10 +0100
Received: from Hehey.local (23-233.197-178.cust.bluewin.ch [178.197.233.23])
	by smtp.webfaction.com (Postfix) with ESMTP id 11C6720887D7;
	Tue, 30 Oct 2012 20:44:06 -0500 (CDT)
Message-ID: <50908263.7050806@erratique.ch>
Date: Wed, 31 Oct 2012 02:44:03 +0100
From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= <daniel.buenzli@erratique.ch>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Francois Berenger <berenger@riken.jp>
CC: caml-list@inria.fr
References: <508F22BD.7010103@riken.jp> <CACX4useWCnu4tg2jAkSx=K=38BaHimgZWRFPF1Jyj5gw+YHAbg@mail.gmail.com> <508F9B56.8090806@riken.jp> <508FBCDC.5000104@gmail.com> <508FD6B3.9080407@inria.fr> <509078DA.6010300@riken.jp>
In-Reply-To: <509078DA.6010300@riken.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Caml-list] Re: Why should I use .mli files?

Francois Berenger a écrit :
 > On 10/30/2012 09:28 PM, Daniel Bünzli wrote:
 >> I personnally find none of these arguments very compelling.
 >
 > "don't take it personally" ;)

Well... really !

> In the first place, I don't want to write those .mli files as the
> compiler can infer them for me automatically (I'm lazy).

Sure, but it infers the most flexible one and there are many case where 
this is not desired. For example if you want to use typing tricks for 
correctness like phantom types you must write mli files.

And at the risk of repeating myself, knowing by a quick glance what is 
internal/external to a module is also very useful information, e.g. if 
you intend to rewrite its functionality. The compiler cannot know what's 
really important for the clients of the module, it exports everything. 
Consider mli files as cheap documentation.

> And I understand that some people need to cast these type signatures
> in stone and constrain them in a different way than the default
> inferred by the compiler, for large projects.

I'm don't thing large/small project really makes a difference here.

A project may be small but still suffer at a certain point of the data 
structure you initially choose (you may even have deliberately done so 
for quick prototyping).

If you didn't care to define a proper abstract datatype via an mli 
file/signature, the rest of the program will very likely access/make 
assumptions about the internal representation of the data structure.

It should be evident that switching to a different data structure is 
going to be much more time consuming than if you had initially taken the 
time to define an abstract datatype.

Best,

Daniel