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 EB92780258 for ; Mon, 3 Jun 2013 13:05:45 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail3-smtp-sop.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: Ak0AAB3yq1GGoCGhhWdsb2JhbABav02CbYEVDgEBAQoLCwUWKIIjAQEEAScLAQVABgsLGAkMCg8JAwIBAgFFEwgBAYgDBrpzjy4KDINCA4keik+DUYYejHqBRg X-IPAS-Result: Ak0AAB3yq1GGoCGhhWdsb2JhbABav02CbYEVDgEBAQoLCwUWKIIjAQEEAScLAQVABgsLGAkMCg8JAwIBAgFFEwgBAYgDBrpzjy4KDINCA4keik+DUYYejHqBRg X-IronPort-AV: E=Sophos;i="4.87,790,1363129200"; d="scan'208";a="16508591" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Jun 2013 03:33:12 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id CDC8B32C00B7 for ; Mon, 3 Jun 2013 10:33:09 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 8A64F32A0085 for ; Mon, 3 Jun 2013 10:33:09 +0900 (JST) Message-ID: <51ABF255.4010109@riken.jp> Date: Mon, 03 Jun 2013 10:33:09 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: caml-list@inria.fr References: <51A81C67.50902@riken.jp> <87bo7rogub.fsf@gmail.com> <51A84283.80309@riken.jp> <51A868F8.9050101@inria.fr> In-Reply-To: <51A868F8.9050101@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.6.3.12418 Subject: Re: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml On 05/31/2013 06:10 PM, Romain Bardou wrote: > I also used to believe the .mli file should be somehow included in the > .ml file. Now I don't. > > 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 trivial to solve. > - Even without numbers it will be harder to get the big picture from a > module. I just propose to generate the .mli automatically (for my projects). Not to get rid of them. > An approach I like about this is Pascal units, with an interface > section and an implementation section, in the same file. But it does not > solve the duplication issue. > > - You need a way to specify abstraction. For instance: > * specify that a type should be exported as "type t" instead of "type > t = A | B"; > * specify that a type should be exported as "type t = private A | B" > instead of "type t = A | B"; > * specify that a value should be exported as "val f: t -> t" instead > of "val f: int -> int" > * specify that a value should be exported as "val f: int -> t" instead > of "val f: 'a -> 'a" I did not think about this yet. > Often, people who want automatic .mli generation do not use abstraction, > which is the main point of interfaces. > > - Don't forget that you need to take into account the whole OCaml > language, including objects, modules, polymorphic variants… It may be > more work than expected. And this project will need to be maintained and > follow the changes to the language. I cannot provide any guarantee, on any of these. Regards, F.