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 8D5737F249 for ; Tue, 30 Oct 2012 17:21:25 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=pra; client-ip=188.165.43.98; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=mailfrom; client-ip=188.165.43.98; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mo3.mail-out.ovh.net) identity=helo; client-ip=188.165.43.98; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="postmaster@mo3.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAAD39j1C8pStimWdsb2JhbABEv3KDeQEBAQEBCAsLBxQngh4BAQQBMgEFQBELGAkWDwkDAgECAUUTCAKHfAYErHeQPot3gzmDJAOSQ4MykzI X-IronPort-AV: E=Sophos;i="4.80,680,1344204000"; d="scan'208";a="160912208" Received: from 14.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net) ([188.165.43.98]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2012 17:21:25 +0100 Received: from mail171.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 782D3FF90E4 for ; Tue, 30 Oct 2012 17:31:26 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 30 Oct 2012 18:21:24 +0200 Received: from gwvisitors.lsv.ens-cachan.fr (HELO ?172.31.81.30?) (romain%bardou.fr@138.231.81.8) by ns0.ovh.net with SMTP; 30 Oct 2012 18:21:22 +0200 Message-ID: <508FFE82.2050409@inria.fr> Date: Tue, 30 Oct 2012 17:21:22 +0100 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.9) Gecko/20121014 Icedove/10.0.9 MIME-Version: 1.0 To: caml-list@inria.fr X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) References: <508F22BD.7010103@riken.jp> <026F32A8-2790-4CDD-A839-58655A8074CA@first.in-berlin.de> <508FE869.3070603@inria.fr> <508FFB12.9030307@gmail.com> In-Reply-To: <508FFB12.9030307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 18339220633529584160 X-Ovh-Remote: 138.231.81.8 (gwvisitors.lsv.ens-cachan.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrudelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeftohhmrghinhcuuegrrhguohhuuceorhhomhgrihhnrdgsrghrughouhesihhnrhhirgdrfhhrqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfedu X-Spam-Check: DONE|U 0.500497/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrudelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeftohhmrghinhcuuegrrhguohhuuceorhhomhgrihhnrdgsrghrughouhesihhnrhhirgdrfhhrqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtkegrtddtfedu X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Why should I use .mli files? Le 30/10/2012 17:06, Edgar Friendly a écrit : > On 10/30/2012 10:47 AM, Romain Bardou wrote: >> Maybe ocaml should provide something like: >> >> include type t in sig >> > Is there any case where type declarations in the .mli file should not be > included as part of the .ml file? No, as it does not compile otherwise. However, maybe the user wants the declarations to be put in some specific order. >> Which would mean "copy-paste the definition of t from the .mli". >> > Why not have this be the default? i.e. when compiling a .ml file, if the > corresponding .mli file exists, its type declarations are in scope for > the .ml file, and its value declarations are applied to the > corresponding values in the .ml file. The only edge case I can think of > is when an identifier is bound multiple times in the .ml file, the type > from the .mli file currently only applies to the last binding, whereas > with this strategy, the type would most easily be implemented as > applying to all bindings of that identifier. > > E. > I'm not sure I understand what you mean, but here are some examples I worry about. 1) You have the following .mli: type t = A type u = A with the following implementation: let x = A Where should type t and type u be copied? In other words, should x be of type t or of type u? It may also happen that the user wants the order of t and u to be reversed in the implementation. 2) You have a declaration like this in the .mli: type t = private something Should it be copied as: type t = something or as: type t = private something I don't think the latter makes much sense most of the time, but it is a valid declaration. You could argue that "if private, then do not copy" but it would make the extension less useful. Probably "if private, copy as not private" is the most sensible thing to do. Cheers, -- Romain Bardou