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 3BA697F249 for ; Wed, 31 Oct 2012 17:50:03 +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.223.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.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.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-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBALdVkVDRVd+2m2dsb2JhbABEw2gIIwEBAQEBCAkLCRQngh4BAQEEEgIkCAEbHAEBAwwGBQsNCRYPCQMCAQIBEREBBQEcBg0BBwEBFweHUQEDDwOdOGIJA4wwgnaEfAoZJw1ZiHUBBQyLbIY7A5V2hWmIeD+ELQ X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="161036669" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Oct 2012 17:50:02 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so4203560iea.27 for ; Wed, 31 Oct 2012 09:50:01 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ta+JD/f1VoGsZIFK/4K2uCmU2CyPkac8/N1H6hgVi4M=; b=NjpMDDnFcMq1vTEJ+ovJ+uM56s51B3WF68gwE/dE3pXOX3hbAAnmvnTvSXPlVq0MzO XcVwAFva4WeThcZDZP+uAt1XDpA6qY0y9BZnwf8e1yFsiPzX30vJ0ETsMuKP3Yq8AuU/ 5C1NaLHDBlPv1AGb1opmf3AYY6s2vk859k7Jl24DyBcYHG8AvE9dgHJ4DOqiQJAFOj91 CWunzqWXvLKSsrMG0MPyr7uT2ebI11QV3tfZooleLuzY+7lX5DYI+OPGQmZJj1L92eP5 TKDV/mbrpGr/2/gNKgtPI6RV0FdLlayNYOSkK0HJkx4WEhO/lJl84HiktISztEnM9JiA mjZA== Received: by 10.50.12.138 with SMTP id y10mr2144286igb.58.1351702201128; Wed, 31 Oct 2012 09:50:01 -0700 (PDT) Received: from [35.9.34.231] (host-55504.dhcp.egr.msu.edu. [35.9.34.231]) by mx.google.com with ESMTPS id ex10sm3510341igc.15.2012.10.31.09.49.12 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 09:49:59 -0700 (PDT) Message-ID: <50915650.3060904@gmail.com> Date: Wed, 31 Oct 2012 12:48:16 -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: Gabriel Scherer CC: 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> <50900466.2050000@gmail.com> <50912C8D.9070600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Why should I use .mli files? On 10/31/2012 11:12 AM, Gabriel Scherer wrote: >> Maybe it's my over-exposure to C++ lately, but I see a clear semantic for >> type re-declaration: >> 1) It is only allowed to re-declare types from the auto-import of a module >> signature >> 2) abstract types can be re-declared arbitrarily >> 3) private foo types can be re-declared to foo >> Nothing else can be re-declared. I missed one case: 4) any type can be re-declared as itself. This uses up the one "re-declaration" that an auto-imported type is allowed. > Why not. We even have a syntax for explicit type overriding: "type! u = int"! > (But if you want to preserve backward-compatibility and still make the > implicit inclusion of the interface in the implementation the default, > you need to allow innocent-looking definitions to have a rebinding > semantics.) Yes, the backwards compatibility is key to my proposal; existing .ml+.mli files would re-declare everything, resulting in all types being as listed in the .ml file. > I liked the idea of reusing the "with type ..." semantics instead of > introducing a new feature, but if this proposal can get rid of the > rather ad-hoc "module type" construct, you're trading one ad-hoc for > another ad-hoc yet potentially simpler feature. I would be happy with > such a langage feature. I hope my solution is not only potentially simpler, but easier for people to use and more natural for people coming to OCaml from other languages where types are declared once. It also allows us to sidestep the issue of type declarations and recursion, as it doesn't depend on any new syntax. E.