From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 9E89DD45F for ; Wed, 2 Nov 2005 13:09:50 +0100 (CET) Received: from mail11.bluewin.ch (mail11.bluewin.ch [195.186.18.61]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jA2C9o6r005383 for ; Wed, 2 Nov 2005 13:09:50 +0100 Received: from [10.0.1.2] (81.62.79.11) by mail11.bluewin.ch (Bluewin 7.2.068.1) id 435DFB6D001A6335; Wed, 2 Nov 2005 12:09:50 +0000 In-Reply-To: <4368AA69.4090504@confluent.org> References: <43679EEF.70102@confluent.org> <875c7e070511011803x598ffb63gd54267aec1fb181e@mail.gmail.com> <4368AA69.4090504@confluent.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: caml-list@yquem.inria.fr Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Nesting Modules Date: Wed, 2 Nov 2005 13:09:55 +0100 To: Tom Hawkins X-Mailer: Apple Mail (2.746.2) X-Miltered: at concorde with ID 4368AC8E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; epfl:01 caml-list:01 nesting:01 cmxa:01 mli:01 defines:01 mli:01 %20:98 unbound:01 define:01 bin:01 cma:01 modules:01 caml-bugs:02 seems:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Le 2 nov. 05 =E0 13:00, Tom Hawkins a =E9crit : > Building a cma/cmxa is fine -- I am working on a library after =20 > all. But for this to work, how are the mli files handled? I tried =20= > several variations of the following, but again, I'm faced with =20 > "Unbound module type Bottom": It is true that when I applied the scheme I described to my own code =20 I inelegantly cut and pasted Bottom's type in Top's one. It seems that although a compiled file a.ml defines a module named A, =20= a compiled file a.mli doesn't define a module type A, strange =20 asymmetry. Apparently an old feature wish about this is in the =20 bugtracking system [1]. Maybe we should wish again ? The problem of =20 the wish is that granting it could break existing code. Daniel [1]