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 541B57F249 for ; Wed, 31 Oct 2012 11:20:38 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.210; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.210; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.210; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAGD6kFDB/BfSlGdsb2JhbAAqGsQQAQEBAQkLCQkUAySCHgEBBThAARALGAkWDwkDAgECAUUGDQEHAQEXh28HLbs9i3gkhhcDlXaBGoRPjUk X-IronPort-AV: E=Sophos;i="4.80,687,1344204000"; d="scan'208";a="179660354" Received: from msa01.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.210]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Oct 2012 11:20:37 +0100 Received: from [192.168.1.108] ([86.195.137.225]) by mwinf5d01 with ME id HmLd1k0054ry3ty03mLdxy; Wed, 31 Oct 2012 11:20:37 +0100 Message-ID: <5090FB75.5010006@frisch.fr> Date: Wed, 31 Oct 2012 11:20:37 +0100 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Gabriel Scherer CC: Edgar Friendly , 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> 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/30/2012 10:25 PM, Gabriel Scherer wrote: > There is another related proposal: Alain Frisch's suggestion to make > compilation units *recursive* modules implicitly, rather than > non-recursive modules. > http://caml.inria.fr/mantis/print_bug_page.php?bug_id=5480 > Using recursive modules induces a definitive amount of complexity, but > is also more expressive in terms of allowing forward references (the > top-to-bottom style aspect I mentioned earlier). I think a simpler, > non-recursive proposition is a more reasonable choice. Alain described > a compromise in use at Lexifi, where compilation units are > *type-checked* are recursive modules but *compiled* as non-recursive > modules. That's probably close in expressivity to this proposal (but > harder, I think, to explain to the newcomer). Type-checking compilation units as recursive modules addresses several issues at the same time: - Mutual recursion between type-level components of different kinds (e.g. a data type declaration and a class type). The current solution is to introduce a local recursive module. - Avoid duplication of type declarations between the interface and the implementation (at least for structural definitions; a type-include feature, as described in the Mantis ticket, would also give a solution for data types). In addition, compiling units as recursive modules (not only for type-checking) would address the common need of forward references and the less common need of allowing recursion between, say, a class definition and a function. The current work-around is to use references to break the recursion, but this is quite an ugly solution (the nice thing with it, though, is that it also works for allowing recursion between several compilation units). Unfortunately, the type-checking and compilation of recursive modules does not seem to be a mastered domain yet, and it sounds dangerous to rely on them for defining the semantics of normal compilation units, at least for now (this is Xavier's argument, and I tend to agree). Hopefully, some more research will give a better understanding of recursive modules... Alain