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 850CD7F249 for ; Wed, 31 Oct 2012 10:51:11 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAOLzkFDAbSoIiWdsb2JhbABEhhe9ViMBAQEVEhQEI4IeAQEEASNWBQsLGAICJgICVwYTG4dlBgSpDJJagSCKWIUoMmEDlXaFaY1J X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="160981663" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2012 10:51:05 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from [192.168.1.9] (178-26-88-14-dynip.superkabel.de [178.26.88.14]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q9V9p07Q032095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Oct 2012 10:51:00 +0100 References: <508F22BD.7010103@riken.jp> <508F9B56.8090806@riken.jp> <508FBCDC.5000104@gmail.com> <508FD6B3.9080407@inria.fr> <509078DA.6010300@riken.jp> <50908263.7050806@erratique.ch> In-Reply-To: <50908263.7050806@erratique.ch> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: Cc: Francois Berenger , "caml-list@inria.fr" X-Mailer: iPad Mail (10A403) From: Oliver Bandel Date: Wed, 31 Oct 2012 10:51:17 +0100 To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] Re: Why should I use .mli files? Am 31.10.2012 um 02:44 schrieb Daniel B=C3=BCnzli : > Francois Berenger a =C3=A9crit : > > On 10/30/2012 09:28 PM, Daniel B=C3=BCnzli wrote: > >> I personnally find none of these arguments very compelling. > > > > "don't take it personally" ;) >=20 > Well... really ! >=20 >> 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). >=20 > Sure, but it infers the most flexible one and there are many case where t= his is not desired. For example if you want to use typing tricks for correc= tness like phantom types you must write mli files. >=20 > And at the risk of repeating myself, knowing by a quick glance what is in= ternal/external to a module is also very useful information, e.g. if you in= tend to rewrite its functionality. The compiler cannot know what's really i= mportant for the clients of the module, it exports everything. Consider mli= files as cheap documentation. [...] The point, some peoplembrought in, was, that after changing the ml-file, the mli is thenold one nevertheless. This also, means, that ocamlc -i will not help here. Thenmli file first mustbbe removed or renamed, to get the output for the ch= anged ml-file. This also has annoyed me sometimes, when I wanted to to get the new default signature. A solution to this problem could be, to have a --force flag, so that ocamlc -i --force would print the default-signature of the raw ml-file, as if the mli file corrosponding to it would not exist. Then the forced ocamlc would print the whole sig of the ml. One could pick out the new stuff then. Or a ocamlc -i --force --diff could print a diff of the signatures of the raw ml-file with unused mli to the signature which is forced by the mli-file. In this way the needed functionality of generating mli-content would be achieved, without changing the classical behaviour of the mli-files. And an implementation seems also to be also comparingly easy. And I would not insist on "--force" and "--diff" as being best choices, but it was just to explain what is meant as proposal. Best regards, Oliver