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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0E6447EE25 for ; Tue, 4 Jun 2013 10:36:51 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBAEmmrVHB/BfUcmdsb2JhbABZgzkBvweBGA4BDAgMCRQDJYIjAQEFOEABEAsYCRYPCQMCAQIBRQYKAwEHAQEXh3a9KI8hBQeDWAOTbYNRgSmEdYx6gTk X-IPAS-Result: AioBAEmmrVHB/BfUcmdsb2JhbABZgzkBvweBGA4BDAgMCRQDJYIjAQEFOEABEAsYCRYPCQMCAQIBRQYKAwEHAQEXh3a9KI8hBQeDWAOTbYNRgSmEdYx6gTk X-IronPort-AV: E=Sophos;i="4.87,798,1363129200"; d="scan'208";a="16675996" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail3-smtp-sop.national.inria.fr with ESMTP; 04 Jun 2013 10:36:50 +0200 Received: from [192.168.1.116] ([92.151.120.247]) by mwinf5d12 with ME id k8co1l00Y5LMejg038co7f; Tue, 04 Jun 2013 10:36:50 +0200 Message-ID: <51ADA720.7070409@frisch.fr> Date: Tue, 04 Jun 2013 10:36:48 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Francois Berenger CC: caml-list References: <51A81C67.50902@riken.jp> <51ACCE6A.7050704@frisch.fr> <51AD351E.9030005@riken.jp> In-Reply-To: <51AD351E.9030005@riken.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] automatic extaction of the .mli (and a little more) from the .ml On 06/04/2013 02:30 AM, Francois Berenger wrote: > - being able to assign priorities to things exported in the > .mli file (to re-order the .mli in some way that makes it easier to > grasp). I think floats should be used and the priority assigned > should be shown in the .mli so that users can quickly see what > priority they need to change in the .ml to obtain the order > they want in the .mli Yes, it's quite easy to add some priority information as an extra argument to the [@mli] attribute. (That said, since extension_points is not yet merged in the official version, I don't think it's worth spending time on the prototype right now.) Showing the priority in the .mli (in the form of attributes) is straightforward (currently, the source syntax pretty-printer pprintast.ml does not support printing attributes, but this will be fixed). > - can you also handle the transfer of ocamldoc comments in the .ml > to the .mli In this form, this is very tricky, because the tool is based on the result of the OCaml parser which does not store the ocamldoc comments. The tool would need to steal from ocamldoc the (complex) logic required to re-parse the source code, extract the attributes, attach them to components of the parsetree/typedtree. What is doable is to have the tool accept more attributes (or more arguments to the [@mli] attribute) representing text to be used as ocamldoc comments in the generated .mli. Instead of producing an AST for the generated signatures (which is then pretty-printed), the tool would directly emit the content of the .mli (with ocamldoc attributes). > (I read later that you also have a final solution > for ocamldoc too)? Certainly not! I'm only suggesting that a tool similar to ocamldoc could be based on attributes, and that it would be more robust and much easier to implement. But designing and implementing this tool is still a serious engineering task, and unless someone puts the required manpower in this project, this is not going to happen. Alain