From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <keiko@kurims.kyoto-u.ac.jp>
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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id 438B0BBAF
	for <caml-list@yquem.inria.fr>; Thu, 21 Aug 2008 11:29:14 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcCADvSrEjAXQIniGdsb2JhbACSHAEBAQ8goxSBZg
X-IronPort-AV: E=Sophos;i="4.32,244,1217800800"; 
   d="scan'208";a="14154113"
Received: from concorde.inria.fr ([192.93.2.39])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Aug 2008 11:29:14 +0200
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m7L9TDS8031859
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK)
	for <caml-list@inria.fr>; Thu, 21 Aug 2008 11:29:13 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcCADvSrEiCNhABiGdsb2JhbACSHAEBAQ8goxSBZg
X-IronPort-AV: E=Sophos;i="4.32,244,1217800800"; 
   d="scan'208";a="16161935"
Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Aug 2008 11:29:11 +0200
Received: from localhost (orion [130.54.16.5])
	by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m7L9T170001564;
	Thu, 21 Aug 2008 18:29:01 +0900 (JST)
Date: Thu, 21 Aug 2008 18:29:01 +0900 (JST)
Message-Id: <20080821.182901.68534700.keiko@kurims.kyoto-u.ac.jp>
To: jeremie.lumbroso@etu.upmc.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Separating two mutually recursive modules
From: Keiko Nakata <keiko@kurims.kyoto-u.ac.jp>
In-Reply-To: <2b7b425b0808201654i61d3f878gbed5c27ca9114438@mail.gmail.com>
References: <2b7b425b0808201654i61d3f878gbed5c27ca9114438@mail.gmail.com>
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-Miltered: at concorde with ID 48AD3569.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; recursive:01 submodules:01 sig:01 node:01 val:01 ideally:01 ideally:01 caml-list:01 cleanly:01 int:01 modules:02 referenced:02 module:03 module:03 scope:04 

Hello,


> I have been unable to cleanly specify the code below (or something
> equivalent) without resorting to Obj.magic. (In the example below,
> "Boxes.B.t" as referenced by the Validator module would ideally simply
> be "Boxes.t", and Validator would not "see" the submodules;)

Can I look at the code which does not type check without Obj.magic?
Ideally something like if I comment out Obj.magic then I get a type error,
and if I comment it in then the code type checks, 
so that I can identify the point of the issue?
(In the context of this simplified example of Boxes & Validator)

>   (********************)
>   (* MODULE Validator *)
>   (********************)
> 
>   and Validator : sig
> 
>     (* This type has been simplified for explanatory purposes. *)
>     (* IDEALLY, Boxes.B.t would simply be B.t. *)
>     type t = Me of int | Node of t * t | B of Boxes.B.t
> 
>     val fold_on_B : (Boxes.B.t -> 'a) -> ('a -> 'a -> 'a) -> 'a -> t -> 'a
> 
>   end =

But B is not in the scope, isn't it?

With best,
Keiko