From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thelema314@gmail.com>
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 715B27F249
	for <caml-list@sympa.inria.fr>; Tue, 30 Oct 2012 17:07:00 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  thelema314@gmail.com) identity=pra; client-ip=209.85.223.182;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="thelema314@gmail.com";
  x-sender="thelema314@gmail.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail1-smtp-roc.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=mail1-smtp-roc.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 (mail1-smtp-roc.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=mail1-smtp-roc.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: AroBANf6j1DRVd+2m2dsb2JhbABEhVG9bwgjAQEBAQEICQsJFCeCHgEBAQQSAiQIARscAgMMBgULDQkWDwkDAgECARERAQUBHBMIAQEeh1EBAw8DnXJiCQOMMIFsgQqFCAoZJw1ZiHUBBQyLa4M5gyQDlXWFaYh4P4Qt
X-IronPort-AV: E=Sophos;i="4.80,679,1344204000"; 
   d="scan'208";a="179565969"
Received: from mail-ie0-f182.google.com ([209.85.223.182])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Oct 2012 17:06:36 +0100
Received: by mail-ie0-f182.google.com with SMTP id k10so1129003iea.27
        for <caml-list@inria.fr>; Tue, 30 Oct 2012 09:06:35 -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=isRgHkMaNQ24Xi90hmZaUkEdIIIh/6VDOl5A1V1d/0g=;
        b=fBiwjm0R6p+ojskV5jU1MkY9X3H1kvCi2TyPV9tq9xdYj45hXx3+1tQgAfYLP46Tjm
         ZR5uN3LQWfpKJo8E8PMEG6uj7i2k7Zg5nCf8WVLj6jgm/4mwxSEeu6xP1ddj3PHhdAGv
         2U0ugFfeM1fXc7EDabYzEzjYnuN3UQE/OuYx6Vnzzhto5qW1Fv1KJrrWf1g81Y0WPikW
         i0E3g29bpD3g0ESNRsnbK/LpLiQ5aZP0hKEsJKALrkmfdQveaJtvcXdXtw0oXxzPqYQ1
         XNuCKgktRmM+DjCGuP0+J8YlG9l+fZbCj+NEpwNNhDuFZf3u+WfmjM5Ch1I5LcK9DeoL
         hhUg==
Received: by 10.50.40.225 with SMTP id a1mr1988715igl.7.1351613195505;
        Tue, 30 Oct 2012 09:06:35 -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 yf6sm807546igb.0.2012.10.30.09.06.33
        (version=SSLv3 cipher=OTHER);
        Tue, 30 Oct 2012 09:06:34 -0700 (PDT)
Message-ID: <508FFB12.9030307@gmail.com>
Date: Tue, 30 Oct 2012 12:06:42 -0400
From: Edgar Friendly <thelema314@gmail.com>
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> <CACX4useWCnu4tg2jAkSx=K=38BaHimgZWRFPF1Jyj5gw+YHAbg@mail.gmail.com> <026F32A8-2790-4CDD-A839-58655A8074CA@first.in-berlin.de> <508FE869.3070603@inria.fr>
In-Reply-To: <508FE869.3070603@inria.fr>
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/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?
> 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.