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 C7DA97F249 for ; Tue, 30 Oct 2012 23:18:20 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8BAJRRkFDAbSoIiWdsb2JhbABEw2YjAQEBFRIUBCOCHgEBBAEnEz8FCwtGITYGE4d0AwkGBKwihkgNiVSLEGeFfGEDlCCBVYVphUiIAQ X-IronPort-AV: E=Sophos;i="4.80,683,1344204000"; d="scan'208";a="179600104" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2012 23:18:20 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from [192.168.1.9] (178-26-88-14-dynip.superkabel.de [178.26.88.14]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q9UMIHmf002638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Oct 2012 23:18:18 +0100 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> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: Cc: Edgar Friendly , "caml-list@inria.fr" X-Mailer: iPad Mail (10A403) From: Oliver Bandel Date: Tue, 30 Oct 2012 23:18:34 +0100 To: Gabriel Scherer X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] Why should I use .mli files? Am 30.10.2012 um 22:25 schrieb Gabriel Scherer : > Independently of this discussion, I have been discussed related issues > with a friend for the last two weeks. I think there would be a feature > proposal to make in this area that would be *relatively* natural and > help solve the following different problems in this area: > 1. Repeating types, module types and class types declarations in the > .mli and the .ml is redundant and increases the maintenance burden Hmhh, not sure if Innserstand whatbyou mean. But as a mli-file narrows the default signature, repeating types mustbe done. An empty mli-file would create an empty signature, and IMHO thats good. Otherwise it would be necessary to have another mechanism to narrow the automatic copying of types. If I missed your pointm then you need to explain in more depth, what you me= an. > 2. The semantics of type-checking the .ml as a whole, and then > checking that it matches the .mli signature is sometimes inconvenient: > checking values against their .mli counterpart could help detect > typing mistakes sooner, which is helpful to get error messages that > are easier to understand What is your argument? pro or contra? It looks weird to me. > 3. Some users want to have annotations on values (at least at > toplevel) for readability and the expression language is not optimal > for this (in particular the fact that type variables do not enforce > polymorphism) ?? >=20 > ## Proposal >=20 > My suggestion would be to allow two features (the second depending on > the first): > 1. allow to insert signature items anywhere in a module structure or > .ml file, giving a reasonable semantics to it > (in particular allow inclusion of signature as a structure item, > with the derived semantics) This is something that possibly would create a big mess, and also seems to mix up interface and implementation for the module language. At least thats my fear. Mybe if its well done, it would work. I just suspect, that something important has been forgotten... > 2. have a syntax to designate the mli signature from the ml file > (possible suggestion: "module type", used a signature expression) >=20 > By combining the two features you could have something like >=20 > a.mli > type t =3D A | B of u > type u > val f : 'a -> 'a >=20 > a.ml > include (module type with type u =3D int) > let f x =3D x ?? >=20 > But you could also write only a.ml: > type t =3D A | B of u > type u =3D int > val f : 'a -> 'a > let f x =3D x ?? If you don't use mli files, then the exported signiture is available and is like what you find inside the ml-file. So what is new here? I,may missed the point, but you can omit mli-files today also.... Ciao, Oliver