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 2ED0F7F249 for ; Thu, 1 Nov 2012 03:43:27 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADnhkVCFBoIF/2dsb2JhbABExGuCHwEFJxwBNw4LRlcGiBinVoQ5AYYoiQEHkVJhiFuNHpBCgn4 X-IronPort-AV: E=Sophos;i="4.80,690,1344204000"; d="scan'208";a="161073630" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Nov 2012 03:43:24 +0100 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id A45DB6340 for ; Thu, 1 Nov 2012 11:43:21 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 79F6640E1 for ; Thu, 1 Nov 2012 11:43:21 +0900 (JST) DomainKey-Signature: h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from garrigue-mini.math.nagoya-u.ac.jp (garrigue-mini.math.nagoya-u.ac.jp [172.16.30.37]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 6D35039A3 for ; Thu, 1 Nov 2012 11:43:21 +0900 (JST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jacques Garrigue In-Reply-To: <5091D90B.6020101@gmail.com> Date: Thu, 1 Nov 2012 11:44:24 +0900 Content-Transfer-Encoding: 7bit Message-Id: <42EF4ECA-C65B-405B-B4BC-A031DA2F2DA9@math.nagoya-u.ac.jp> 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> To: OCaml List X-Mailer: Apple Mail (2.1499) Subject: Re: [Caml-list] Why should I use .mli files? 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. My conclusion has unfortunately been that trying to solve this at the language level without breaking backward compatibility is very difficult. For instance, one is currently allowed to do something like that: a.ml: let f x = x let b = f true a.mli: val f: int -> int This may look stupid, but this kind of code (of course more complicated) exists in the wild, and sometimes for sensible reasons. For this kind of reason, I do not see any easy way to import information from mli files to ml files. Now, is maintaining mli files really painful? In my experience, not at all. Taking as example the ocaml compiler itself, the only duplication that bothers me a little is the error type exported by many modules, as one always has to keep it in sync by copy-paste. This is a bit of a problem because for most uses this type could be abstract (you don't really care about its contents), but in some rare occasions you need it public. For other types, do not see syncing as a disadvantage, because it rather makes you conscious that other modules depend on this type, so better look at it twice :-) Of course I know that some people (probably with a different background) do not like mli files. Couldn't we just imagine a preprocessing tool that allows to generate both ml and mli from the same file? This is pretty standard for literate programming. It could even call the compiler if you want the types to be inferred automatically (even though I personally think that having to write value types in the mli file is good, because you know when you are changing an export.) As an external tool, it could use pragmas (keywords inside comments) for instance. Something close to ocamldoc (ocamldoc itself?) but which you would integrate in the compilation cycle. Anyway, I just wanted to state, from my experience, my lack of enthusiasm about modifying the core language to accommodate that. Jacques Garrigue