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 DD7AD7F249 for ; Thu, 1 Nov 2012 08:46:03 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rossberg@mpi-sws.org) identity=pra; client-ip=139.19.1.49; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of rossberg@mpi-sws.org designates 139.19.1.49 as permitted sender) identity=mailfrom; client-ip=139.19.1.49; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; 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@hera.mpi-klsb.mpg.de) identity=helo; client-ip=139.19.1.49; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="postmaster@hera.mpi-klsb.mpg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQBAHUnklCLEwExe2dsb2JhbABEgyzAYAEBFiYFIoIeAQEBBDgCBgEBOA8LGC5XBogZBKdphDMBBY8kBot7hVphqSw X-IronPort-AV: E=Sophos;i="4.80,691,1344204000"; d="scan'208";a="161088496" Received: from hera.mpi-sb.mpg.de (HELO hera.mpi-klsb.mpg.de) ([139.19.1.49]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 01 Nov 2012 08:46:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=References:Date:Mime-Version:Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:To:From:Message-Id; bh=pgy7P6c3oJYnb5gf3TkdSz+PdeNcRcIpKJfXQ8FRlQc=; b=O3pK1qrkeP9Twou+51nL4G+8+8lY2HaWb3ileYOBvq73SvHPRGwMrr2eD2Sm+Zxr0SoVtAfO08zOrSv2nHaBSxrFzUpxv3MmdqIiUkyU9dsGatBc78l95+UzupTAkf+z2c5M+fQ2Nyv+UQFv3LDkRr/yq9gybJHjIVu0ftLTMtY=; Received: from maniac.mpi-klsb.mpg.de ([139.19.1.28]:37481) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtp (Exim 4.72) id 1TTpTU-00036R-MH; Thu, 01 Nov 2012 08:46:02 +0100 Received: from mnch-5d85fc47.pool.mediaways.net ([93.133.252.71]:65174 helo=[192.168.178.31]) by maniac.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) id 1TTpTU-0001Sf-5n; Thu, 01 Nov 2012 08:46:00 +0100 Message-Id: From: Andreas Rossberg To: OCaml List In-Reply-To: <42EF4ECA-C65B-405B-B4BC-A031DA2F2DA9@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Nov 2012 08:45:59 +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> <5090F66F.60803@erratique.ch> <50912619.9090004@gmail.com> <5091C47D.4070501@riken.jp> <5091C584.1010607@gmail.com> <5091C7E8.7090007@riken.jp> <5091D90B.6020101@gmail.com> <42EF4ECA-C65B-405B-B4BC-A031DA2F2DA9@math.nagoya-u.ac.jp> X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] Why should I use .mli files? On Nov 1, 2012, at 03.44 h, Jacques Garrigue wrote: > Wow. > I see that a big debate is going on mli files and declarations > inside ml files. > > I think that lots of people have given this problem a lot of thought > during many years. > > [...] > > Now, is maintaining mli files really painful? > In my experience, not at all. I strongly second that. Separation of interface and implementation _is a feature_! In fact, it is one of the high marks of ML modules (as opposed to, say, privacy in Java classes, let alone the mess that is C/ C++ style header files). Its semantics is simple but powerful. The separation improves modularity by naturally encouraging abstraction, low coupling, and documentation. Better modularity makes for better maintainability. And the separation makes code more readable -- which, as others have noted, is 10 times more important than making it more writable, for anything but trivial projects (i.e., anything where modules are actually needed). No doubt you can find cases where the redundancy is unfortunate. Mainly these are ones involving larger data type definitions that refer to abstract types from the same module, and hence cannot easily be factored out into a separate module. But in my experience, such cases are rare, and the minor inconvenience is far outweighed by the overall benefits. /Andreas