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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 5A9CF7F249 for ; Wed, 31 Oct 2012 14:44:35 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.210.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.210.182 as permitted sender) identity=mailfrom; client-ip=209.85.210.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.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=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@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: AtEBADsqkVDRVdK2m2dsb2JhbABEsUGSIwgjAQEBAQEICQsJFCeCHgEBAQMBEgITGQEbEgsBAwELBgULAwoNISEBAREBBQEKEgYTEhCHUQEDCQYLnF5iCQOMMIJ2hHQKGScDClmIdQEFDIsFZ4Y7A5QhgVWBGooXgzAWKYQS X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="179693651" Received: from mail-ia0-f182.google.com ([209.85.210.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Oct 2012 14:44:34 +0100 Received: by mail-ia0-f182.google.com with SMTP id k10so1837647iag.27 for ; Wed, 31 Oct 2012 06:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+SzzZOyTeRW4gO4jr060VhxbP0r3aiI+XUAz5O0jQls=; b=EHWo3PKptCepJrw7GvCM6NdD6bGD5idAnjYkAXq9BYZqhyxftpOtoND1s8W7R3M+Bx h1/4RCrz3PvvZx7WflRJ/8Wv8Td6pmOu4BMBdvUe6pft89xMX95tyXml5yRKsrScOeSN 3aUmCHAK6iveF78UJreAZEs5w38iu8Bc53R6RSlO5fKTjIHNuJ5OkVnweZl7omVix98V DgeM4NHUDJmtp76lSNtGYPWvL0ku9C+MthitcfwyBUZmwKp4oN5AznGOLURmw1Gke89G q+YTbdbWRJTLILUGKDaWzftyPN9cV+PThnhCkbsMg/EYw2oBdKYj3c/y314EKAwFyg6G J+6Q== Received: by 10.50.185.168 with SMTP id fd8mr1488963igc.51.1351691073217; Wed, 31 Oct 2012 06:44:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.65.9 with HTTP; Wed, 31 Oct 2012 06:43:53 -0700 (PDT) In-Reply-To: <50912619.9090004@gmail.com> 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> <50900466.2050000@gmail.com> <5090F66F.60803@erratique.ch> <50912619.9090004@gmail.com> From: Gabriel Scherer Date: Wed, 31 Oct 2012 14:43:53 +0100 Message-ID: To: Edgar Friendly Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Why should I use .mli files? > It makes sense to me that such a signature item in a .ml file should be > restricted to being immediately before the value binding it applies to. It makes sense, but then the (include (module type)) feature I was proposing to avoid duplicating transparent definition from the .mli into the .ml doesn't work anymore. I need a sufficiently relaxed syntax that allows to put signature items at the top of the file and use them afterwards. I don't think any restriction of this kind would be sufficient nor necessary to dispel Daniel's fears. Daniel, I fully agree that .mli are helpful and should be preserved, and my suggestion was precisely in the sense of making the .ml/.mli combination more convenient for users, so that they would have less incentive to use the .ml alone. There is not much in the feature proposal that would allow to get rid of the .mli anymore that it currently is the case, so I don't understand your opposition based on this particular argument. (On the other side, I must note that your argument that ".ml/.mli redundancy should be handled by tooling" could be reused in the converse direction: the .mli (including documentation if present in the source) could be produced from the .ml by tooling. In the absence of such tooling, I don't give much weight to either arguments which are a modern form of the too-convenient Sufficiently Smart Compiler point of view.) On Wed, Oct 31, 2012 at 2:22 PM, Edgar Friendly wrot= e: > On 10/31/2012 5:59 AM, Daniel B=FCnzli wrote: >> >> Gabriel Scherer a =E9crit : >>> >>> Allowing signatures items in structures and .ml files alone does not >>> increase the expressivity of the language. >> >> I'm against this idea. This means that you have to skim trough the whole >> ml file to actually understand what the module signature is. This is very >> inconvenient. > > It makes sense to me that such a signature item in a .ml file should be > restricted to being immediately before the value binding it applies to. > i.e. > > val foo : 'a -> 'a > let foo x =3D x > > would be legal, while the following would not be allowed: > > val foo: 'a -> 'a > val bar: int -> string > let foo x =3D x > let bar =3D string_of_int > > This should solve the "skim through the whole ml file" problem. > > E. > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs