From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 17C06BC69 for ; Fri, 28 Dec 2007 11:02:19 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADlYdEeCNhAB/2dsb2JhbACRXZso X-IronPort-AV: E=Sophos;i="4.24,215,1196636400"; d="scan'208";a="6099348" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Dec 2007 11:02:17 +0100 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id lBSA2AMa009633; Fri, 28 Dec 2007 19:02:10 +0900 (JST) Date: Fri, 28 Dec 2007 19:02:10 +0900 (JST) Message-Id: <20071228.190210.68534327.keiko@kurims.kyoto-u.ac.jp> To: zoltan.s.mark@dravanet.hu Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Type visibility limitation in recursive modules From: Keiko Nakata In-Reply-To: <47743194.1080801@dravanet.hu> References: <476E6FB7.6040100@dravanet.hu> <476F9B82.2060103@dravanet.hu> <47743194.1080801@dravanet.hu> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; recursive:01 ocaml:01 checker:01 recursively:01 caml-list:01 caml-list:01 constructor:01 modules:02 caml:02 defined:02 external:03 module:03 scope:04 hack:04 problem:05 Hello. I have not thoroughly read your posts, but it looks like the double vision problem. You may be interested in the following post to camllist: http://caml.inria.fr/pub/ml-archives/caml-list/2007/06/0d23465b5b04f72fedecdd3bbf2c9d72.en.html By the way, I believe one can hack the OCaml type checker to (mostly) avoid the problem by "strengthening" the external signature of the recursively defined module in the type environment. But this is not particularly beautiful since a type constructor may escape its scope, although the implementation is kept sound. I would be very happy if you could give me a practical example which suffers from the double vision problem. A happy new year! Keiko