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 3F3167F249 for ; Wed, 31 Oct 2012 14:55:30 +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: AtIBAH0skVDRVd+2m2dsb2JhbABEhhe9TQgjAQEBAQEICQsJFCeCHgEBAQQSAg8PAQUIARscAQEDDAYFCw0CAgUWCwICCQMCAQIBEREBBQEcBg0BBwEBHodRAQMPnGtiCQOLYU+CdoR0ChknDVmIdQEFDIEUiliFKIETA5V2hWmIeD+ELQ X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="179695687" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Oct 2012 14:55:29 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so3677837iea.27 for ; Wed, 31 Oct 2012 06:55:28 -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=tPoIVF2cZxgdZoaYNuoazxrOFsYM+ZX117Ykq4tBq40=; b=xwaBfqmXd3e2X/1c7Cv0BOvQmf3HKUmmBmEJ+Ejdw0sRg08Ka7zTsc90LPyM6tklEu hqB243lnHOsnlekI6m2zoicU4ojvciQ/lcYgJn4PlZnXsH5qh8rHly8rwsCCByIKJIbw 6RZF8kbeHoRWGpr4RMLdK1k0RUjzsypHZEzqII4crGXr0JGqKv8ICt33qZsFQb7NnXdt 9yjG7QVvAdGA2Gq9wcumeXBRU69gXvB3ipFeF1VKyVhpa93RkmI/De1XbUOZtix3+zhv dJ1Vt6kfzMHWpGQngmdFvqVJTUMP1Pm7VwzYr5fgV5T3CZSzWbjYwM0OavVBMZz1ym69 WVAA== Received: by 10.50.178.67 with SMTP id cw3mr1469033igc.53.1351691728290; Wed, 31 Oct 2012 06:55:28 -0700 (PDT) Received: from [192.168.1.73] (99-121-78-10.lightspeed.lnngmi.sbcglobal.net. [99.121.78.10]) by mx.google.com with ESMTPS id uj6sm3182140igb.4.2012.10.31.06.55.26 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 06:55:27 -0700 (PDT) Message-ID: <50912DD7.2070502@gmail.com> Date: Wed, 31 Oct 2012 09:55:35 -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: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= 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> <5090F66F.60803@erratique.ch> <50912619.9090004@gmail.com> <509129D2.3050705@erratique.ch> In-Reply-To: <509129D2.3050705@erratique.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Why should I use .mli files? On 10/31/2012 9:38 AM, Daniel Bünzli wrote: > The problem is not for a single value. The problem is understanding > what this modules actually exports and hence the information flow > between the larger program and that module. With this proposal that > information is scattered across the whole module among intermediary, > hidden, definitions. > > An mli summarizes very well the actual interface of the module without > being distracted by the way the code is actually organized in the > module. It's a huge tool for understanding programs. > Best, > > Daniel Ah, I misunderstood your criticism. You're right, we should keep .mli files as the great summary of the interface of .ml files. I'm pretty neutral about having type declarations (val foo : ) in the .ml file, as this is just another duplication of what needs to be in the .mli file. I think that the information in the .mli file should directly impact the compilation of the .ml file, in that types declared there should be available in the .ml file, and the types given to identifiers should be applied to bindings for those identifiers as they're being compiled (so that int specialization can produce better compiled code, for one example). E.