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 D2DF77F249 for ; Tue, 30 Oct 2012 17:46:26 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of thelema314@gmail.com) identity=pra; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="thelema314@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of thelema314@gmail.com designates 209.85.210.182 as permitted sender) identity=mailfrom; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="thelema314@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ia0-f182.google.com) identity=helo; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="postmaster@mail-ia0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBAHkDkFDRVdK2mGdsb2JhbABEw0gIIwEBAQEBCAkNBxQngh4BAQEEEgIeAQUIARscAgMMBgULDQkWDwkDAgECARERAQUBHBMIAQEeh1EBAw8DnXJiCQOMMIFsgQqFBgoZJw1ZiHUBBQyLa4M5gyQDkkODMoVpiHg/hC0 X-IronPort-AV: E=Sophos;i="4.80,680,1344204000"; d="scan'208";a="160915453" Received: from mail-ia0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Oct 2012 17:46:25 +0100 Received: by mail-ia0-f182.google.com with SMTP id k10so579535iag.27 for ; Tue, 30 Oct 2012 09:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YoQDiwk9tR+JYKrIiOslTYKpSgu2rzlJnjgK6AKUHnc=; b=PO0+xOD0/FsjH5p72vVdHsuWRDTg9QXBuU81mXOp8p1F4Cud4twQ8I2e0ZNfMiE0dY 9312iiJlH0f5RrYChnhVv5ioPxnfwa9CDhwn6MESYiZD4axFiLuQIbw+fUch+73/rYXv fVtOtazPktdej1xNFi8MO/eWr5ugzhpBwxm8cxR6CcNqZYDPGt6DPtzjdrjzfFu1bTJO PKkrI86rWtDLDIYvA45JZULzdMGXpQ78tTzau90kkjZsnistrxDNGEpAN/z86ygrS5kb 7Qe97PwHo2NFqHl41unsXIV/ZBatwoyL/d8MxoDGGeuqZLfV+beyEB9kcmnw8nkSRMzN J4Pg== Received: by 10.50.10.199 with SMTP id k7mr2027652igb.70.1351615584295; Tue, 30 Oct 2012 09:46:24 -0700 (PDT) Received: from [35.9.35.91] (host-55504.dhcp.egr.msu.edu. [35.9.35.91]) by mx.google.com with ESMTPS id az6sm8362517igb.11.2012.10.30.09.46.22 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:46:22 -0700 (PDT) Message-ID: <50900466.2050000@gmail.com> Date: Tue, 30 Oct 2012 12:46:30 -0400 From: Edgar Friendly User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: caml-list@inria.fr References: <508F22BD.7010103@riken.jp> <026F32A8-2790-4CDD-A839-58655A8074CA@first.in-berlin.de> <508FE869.3070603@inria.fr> <508FFB12.9030307@gmail.com> <508FFE82.2050409@inria.fr> In-Reply-To: <508FFE82.2050409@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Why should I use .mli files? On 10/30/2012 12:21 PM, Romain Bardou wrote: > 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? > They could be copied to the top of the .ml file in the order specified in .mli file. > 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. > Or the user could specify "type t = something" in the .ml file and override the .mli file's type. To do this, we'd need the concept of these "copied" types being overrideable in the .ml file, but I think doing this would be necessary for backwards compatibility, as all existing code would break under the new .mli semantics. E.