From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <berenger@riken.jp>
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 557157F249
	for <caml-list@sympa.inria.fr>; Thu,  1 Nov 2012 03:37:46 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  berenger@riken.jp) identity=pra; client-ip=134.160.33.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="berenger@riken.jp";
  x-sender="berenger@riken.jp"; x-conformance=sidf_compatible
Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of
  berenger@riken.jp designates 134.160.33.175 as permitted
  sender) identity=mailfrom; client-ip=134.160.33.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="berenger@riken.jp";
  x-sender="berenger@riken.jp"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of
  postmaster@postman.riken.jp designates 134.160.33.175 as
  permitted sender) identity=helo; client-ip=134.160.33.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="berenger@riken.jp";
  x-sender="postmaster@postman.riken.jp";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlABAPrfkVCGoCGvhWdsb2JhbABEwByDagEBAQoLCwUWJ4IeAQEEAThAEQsYCRYPCQMCAQIBRRMIAQEXh2UGuz+LeIMXgyQDiFiNHoVpjVc
X-IronPort-AV: E=Sophos;i="4.80,690,1344204000"; 
   d="scan'208";a="179770017"
Received: from postman3.riken.jp (HELO postman.riken.jp) ([134.160.33.175])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Nov 2012 03:37:21 +0100
Received: from postman.riken.jp (postman3.riken.jp [127.0.0.1])
	by postman.riken.jp (Postfix) with SMTP id 784D938380E9
	for <caml-list@inria.fr>; Thu,  1 Nov 2012 11:37:18 +0900 (JST)
Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98])
	by postman.riken.jp (Postfix) with ESMTPA id 40E6F382024B
	for <caml-list@inria.fr>; Thu,  1 Nov 2012 11:37:18 +0900 (JST)
Message-ID: <5091E05E.1090803@riken.jp>
Date: Thu, 01 Nov 2012 11:37:18 +0900
From: Francois Berenger <berenger@riken.jp>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: caml-list@inria.fr
References: <508F22BD.7010103@riken.jp> <CACX4useWCnu4tg2jAkSx=K=38BaHimgZWRFPF1Jyj5gw+YHAbg@mail.gmail.com> <026F32A8-2790-4CDD-A839-58655A8074CA@first.in-berlin.de> <508FE869.3070603@inria.fr> <508FFB12.9030307@gmail.com> <508FFE82.2050409@inria.fr> <50900466.2050000@gmail.com> <CAPFanBHcmSy3vAS8G+CHey1YZ-6kyYxxgtHJdkt40fmr54Fw1g@mail.gmail.com> <B4888D11-BF86-4756-B529-4D71486B2C8A@first.in-berlin.de> <CAPFanBEHu6ZWm1j0zvsAAWjmnHB4NbsRRTBH18qhOK9yWVA+pA@mail.gmail.com> <5090F66F.60803@erratique.ch> <50912619.9090004@gmail.com> <CAPFanBE+dyP2=bqXdVNVi2h=yGA+eqS7Faho=ZuKbf2HEH21jA@mail.gmail.com> <5091C47D.4070501@riken.jp> <5091C584.1010607@gmail.com> <5091C7E8.7090007@riken.jp> <5091D90B.6020101@gmail.com>
In-Reply-To: <5091D90B.6020101@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.1.22433
Subject: Re: [Caml-list] Why should I use .mli files?

On 11/01/2012 11:06 AM, Edgar Friendly wrote:
> On 10/31/2012 8:52 PM, Francois Berenger wrote:
>> If the .mli is generated automatically from the .ml,
>> including documentation, people can still read their dear
>> .mli file (once it has been generated).
> Why bother generating a .mli file if this is the only goal;

 From what I understood from previous posts, .mli files
also accelerate compilation of large projects by preventing
recompilation of some things when there is an implementation
change without an interface change.

So, I understand they don't have a "documentation"-only goal.

 > instead,
> just use ocamldoc to build documentation exactly for the exported
> interface.

I guess my friend Daniel Bunzli will want to do this. ;)

 > But this still needs some backwards-compatible magic to
> indicate the public interface in the .ml file, and I don't think we have
> a good solution to this at the moment.

I am not advocating for the disappearance of .mli files.

I just don't want to have to bother with them manually
or have to maintain them because to me everything
can be said in a central place, the .ml file.
But that's just my personal taste.

Regards,
F.