From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 3B3547EE25 for ; Tue, 4 Jun 2013 11:05:24 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=81.103.221.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of dra-news@metastack.com does not assert whether or not 81.103.221.48 is permitted sender) identity=mailfrom; client-ip=81.103.221.48; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mtaout02-winn.ispmail.ntl.com) identity=helo; client-ip=81.103.221.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@mtaout02-winn.ispmail.ntl.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAAHOtrVFRZ90wlGdsb2JhbABZgmi8coJogQIWDgEBAQEHDQkJFAMeB4IjAQEBAwEnVwsCAQgYCiQyJQIEGxOHbAcDvSaOdTiCd2EDiGiLBYNRkxiBN4In X-IPAS-Result: AlsAAHOtrVFRZ90wlGdsb2JhbABZgmi8coJogQIWDgEBAQEHDQkJFAMeB4IjAQEBAwEnVwsCAQgYCiQyJQIEGxOHbAcDvSaOdTiCd2EDiGiLBYNRkxiBN4In X-IronPort-AV: E=Sophos;i="4.87,798,1363129200"; d="scan'208";a="20211521" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail2-smtp-roc.national.inria.fr with ESMTP; 04 Jun 2013 11:05:16 +0200 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130604090515.KWZL23282.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Tue, 4 Jun 2013 10:05:15 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130604090515.PDSY2660.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com> for ; Tue, 4 Jun 2013 10:05:15 +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 r5495DHZ007746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Jun 2013 10:05:13 +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 10:05:13 +0100 From: David Allsopp To: "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///7mgCAABoa4A== Date: Tue, 4 Jun 2013 09:05:13 +0000 Message-ID: References: <51A81C67.50902@riken.jp> <87bo7rogub.fsf@gmail.com> <51A84283.80309@riken.jp> <51A868F8.9050101@inria.fr> <51ADA3C2.7020302@inria.fr> In-Reply-To: <51ADA3C2.7020302@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="iso-8859-1" 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=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=IXlcok0kcmcA:10 a=WqH6JILulzsA:10 a=cTs9vV391PwA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=Djb2HxWtbS_48nti7MsA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: RE: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml Romain Bardou wrote: > Le 04/06/2013 09:53, David Allsopp a =E9crit : > > 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. > > > >> But if you design such a tool, here are some things to consider. > >> > >> - 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. >=20 > Agreed, obviously. It seems Fran=E7ois proposes floats as a solution, but > while it does allow you to insert without renumbering everything, it seems > that with time, you'd end up with a messy file. Yes - I'd said in a private exchange that using floats is no different from= the way Basic programmers used to leave gaps between line numbers! Eventua= lly you need to renumber... > > 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 .mli file automatically" rather than "how can we *import* from the > .ml file automatically". 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: >=20 > I agree with the idea of looking the other way around, but I'm not sure I > agree with your proposal, which seems to *not* be the other way > around: in your example, you write "type t from implementation", in the > .mli. I would prefer "type t from interface" from the .ml. My perspective was that it looks at what we write in the .ml file being *ex= ported* to the .mli file and I was proposing that what we write in the .mli= file be *imported* from the .ml file (which I would say is indeed the othe= r way around). But as I said in response to Alain, perhaps that's not actua= lly the good idea I thought it was, given that .mli files are used in conte= xts where the .ml file isn't available. I agree that putting the copy state= ment in the .ml file is better.=20 > Also, I agree that val and let is not duplication as long as the let is > not annotated. Duplication comes from types and module type declarations, > exceptions, and maybe also classes. >=20 > Regarding val and let, if the types don't match, the error is better > located than before in recent versions of OCaml. But it could be even > better if the let could be retyped with inlined type annotations. >=20 > Here is an example: >=20 > val f: int -> int >=20 > let f x =3D x +. 1. >=20 > The error is located on f (it has type float -> float instead of int -> > int). But maybe it would be better if it was located on x or +. as if the > function was actually written like this: >=20 > let f (x: int): int =3D x +. 1. >=20 > Why do I bring that up? Well this would go in the sense of avoiding > duplication by avoiding the need of adding the type annotations yourself > to get better error location. I guess that depends on what you regard as the error, though - the definiti= on of [f] with floats is not incorrect, it just doesn't comply with the sig= nature you've imposed. Personally, I'm happy with the idea that the compile= r reports that the signature of [f] differs between the implementation and = interface and leaves me to figure out why that's a mistake, but...=20 > But this brings up other questions, such as: what if a function f is > polymorphic in the implementation and used as such, but is exported as a > monomorphic instance: if you import type annotations from the .mli, you > cannot use the polymorphism of f in the implementation anymore. Unless the > type annotations are only used to obtain better error messages, only when > there is a type mismatch between the mli and the ml. That's kind of why I was thinking that you only have an "extension" for typ= es which are *actually* duplicated between the two. However, perhaps it's s= omething that is relatively easy with the kind of extension Alain proposes = so that you could write in the .ml file: let [%unify_typedef] f =3D x +. 1. so that you're saying that the type of [f] must be unifiable (rather than c= opied) from the .mli... which would catch the case of f : float -> float an= d state that either [+.] or [x] is the problem but also allow you to have a= polymorphic function in the implementation with a monomorphic exported typ= e. David