From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5F47A7EE25 for ; Tue, 4 Jun 2013 09:53:49 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=81.103.221.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com does not assert whether or not 81.103.221.52 is permitted sender) identity=mailfrom; client-ip=81.103.221.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mtaout04-winn.ispmail.ntl.com) identity=helo; client-ip=81.103.221.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@mtaout04-winn.ispmail.ntl.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAALqbrVFRZ900nGdsb2JhbABZgmhRvwaBABYOAQEBAQEGDQkJFCiCIwEBAQMBJxNECwIBCBgKFBAyJQIEARqHfwcDvROOdTiCd2EDk22DUZMYgTeCJw X-IPAS-Result: AooAALqbrVFRZ900nGdsb2JhbABZgmhRvwaBABYOAQEBAQEGDQkJFCiCIwEBAQMBJxNECwIBCBgKFBAyJQIEARqHfwcDvROOdTiCd2EDk22DUZMYgTeCJw X-IronPort-AV: E=Sophos;i="4.87,798,1363129200"; d="scan'208";a="16668698" Received: from mtaout04-winn.ispmail.ntl.com ([81.103.221.52]) by mail3-smtp-sop.national.inria.fr with ESMTP; 04 Jun 2013 09:53:48 +0200 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout04-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130604075347.LXBS8801.mtaout04-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 4 Jun 2013 08:53:47 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130604075347.JVDY6472.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com>; Tue, 4 Jun 2013 08:53:47 +0100 Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id r547riaq007173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 08:53:44 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0123.003; Tue, 4 Jun 2013 08:53:44 +0100 From: David Allsopp To: Romain Bardou , "caml-list@inria.fr" Thread-Topic: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml Thread-Index: AQHOXbEfSaBAF3FKQU2pLmZI8Q/+85kexO87///+Z4CAAC3YAIAGQFww Date: Tue, 4 Jun 2013 07:53:44 +0000 Message-ID: References: <51A81C67.50902@riken.jp> <87bo7rogub.fsf@gmail.com> <51A84283.80309@riken.jp> <51A868F8.9050101@inria.fr> In-Reply-To: <51A868F8.9050101@inria.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Cloudmark-Analysis: v=1.1 cv=AUhbpHVS+xhHrj9wLCYAQoYnFLYUZdbP8UM0GmH2jwk= c=1 sm=0 a=IXlcok0kcmcA:10 a=WqH6JILulzsA:10 a=cTs9vV391PwA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=OsdYDu0FkERgdrBRIMsA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: RE: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml Romain Bardou wrote: > I also used to believe the .mli file should be somehow included in the .ml > file. Now I don't. +1, FWIW! It's easy to start without the .mli when prototyping and then add= it as things mature. =20 > But if you design such a tool, here are some things to consider. >=20 > - Using numbers to order stuff creates some issues of scalability. In > particular, inserting a declaration between #3 and #4 may require you to > move #4 to #5, #5 to #6 and so on, which (in particular if everything is > not in the right order in the implementation) can prove more annoying than > reordering stuff in an .mli. This is horrible, IMO - any design decision which looks like it'll *require= * refactoring support from an editor to be able to work with it strikes me = as a bad design decision. If you have hundreds of these in a file, at some = point you'll need a "renumber everything" macro. I have wondered if this problem is perhaps looked at the wrong way around -= in other words, the complaint takes the form "how can we export to the .ml= i file automatically" rather than "how can we *import* from the .ml file au= tomatically". The thing I do find irritating maintaining .mli/.ml files is = having to type anything out twice - and for the most part that means fully = exported type declarations. Say you have a simple module: Foo.mli (separate file, so the items can appear in a different order trivia= lly) =3D=3D=3D=3D=3D=3D=3D (** Foo. This module is an example *) (** Annotation *) type t =3D A (** Annotation *) | B (** Annotation *) val bar : t -> bool (** [bar x] returns true if [x] is [A] *) Foo.ml =3D=3D=3D=3D=3D=3D type t =3D A | B (* This duplication is annoying *) let bar x =3D (x =3D A) (* No type declaration needed here *) For me, "val bar" in the .mli and "let bar" in the .ml is not duplication a= s one is the implementation and the other is the exported type. However, I = do find having to maintain type t in two files irritating (say if I want to= add the constructor C) - especially if t has hundreds of constructors wher= e you have to make sure the order is the same too, of course. What would be= nice would be to be able to put this in the /.ml/ file:=20 (** Annotation *) type t =3D A (** Annotation *) | B (** Annotation *) and then this in the /.mli/ file: type t from implementation or=20 export type t which would export the entire declaration and also its ocamldoc comments. F= or an opaque type, you have different declarations anyway, so just write th= em. The same would be true of module types and so on. Just my 2p! David