From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Julien.Signoles@lri.fr>
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
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id C9527BBCA
	for <caml-list@yquem.inria.fr>; Tue, 26 Feb 2008 10:36:10 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAI9sw0eBrw8Eh2dsb2JhbACQZAEBAQgKKZtP
X-IronPort-AV: E=Sophos;i="4.25,406,1199660400"; 
   d="scan'208";a="9598984"
Received: from ext.lri.fr ([129.175.15.4])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Feb 2008 10:36:10 +0100
Received: from localhost (localhost [127.0.0.1])
	by ext.lri.fr (Postfix) with ESMTP id 53B2BA44BD;
	Tue, 26 Feb 2008 10:36:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lri.fr
Received: from ext.lri.fr ([127.0.0.1])
	by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id IS34K2c2Z4wN; Tue, 26 Feb 2008 10:36:10 +0100 (CET)
Received: from smtp.lri.fr (vhost3-23 [129.175.3.23])
	by ext.lri.fr (Postfix) with ESMTP id 3BE5DA4472;
	Tue, 26 Feb 2008 10:36:10 +0100 (CET)
Received: from serveur9-10.lri.fr (serveur9-10 [129.175.9.10])
	by smtp.lri.fr (Postfix) with ESMTP id 4B843E0532;
	Tue, 26 Feb 2008 10:36:10 +0100 (CET)
Received: from localhost ([127.0.0.1] ident=signoles)
	by serveur9-10.lri.fr with esmtp (Exim 3.36 #1 (Debian))
	id 1JTwEM-0000CD-00; Tue, 26 Feb 2008 10:36:10 +0100
Date: Tue, 26 Feb 2008 10:36:10 +0100 (CET)
From: Julien Signoles <Julien.Signoles@lri.fr>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OO programming
In-Reply-To: <20080226.151750.16504093.garrigue@math.nagoya-u.ac.jp>
Message-ID: <Pine.LNX.4.63.0802261027430.501@serveur9-10.lri.fr>
References: <47BD44FE.3050001@irisa.fr> <20080226.151750.16504093.garrigue@math.nagoya-u.ac.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam: no; 0.00; signoles:01 signoles:01 lri:01 modular:01 coherence:01 bug:01 recursive:01 sig:01 struct:01 struct:01 bug:01 recursive:01 ideally:01 rec:01 rec:01 


>> Hence my question: does anyone knows a way of combining the reusability
>> of sets of related classes with a more modular (type/consistency)-checking ?
>
> I'm not sure whether it helps, but I attach here the same example of
> observer pattern as in the tutorial, but without using type
> parameters. They are replaced by private row types.
>
> Ideally, one would like to check coherence too by writing
>  module rec Check : S' = Window(Check)
> Unfortunately, this doesn't seem to work currently. I'm not yet sure
> whether this is a bug or a limitation of recursive modules.

As far as I understand the Jacques' code, the following check seems to 
work

===
module rec Check : sig
   type event = private [> `Move]
   type subject = private <draw: unit; ..>
   type observer = private < notify : Check.subject -> Check.event -> unit; .. >
end = struct
   include Window(Check)
   type event = Check.event
end
===

I don't know exactly why one has to write "Check.subject" and 
"Check.event" in the signature. The consequence is that the following 
code just does not work.

===
module rec Check : S' = struct
   include Window(Check)
   type event = Check.event
end
===

As Jacques said, it is either a bug or a limitation of recursive modules.
I don't know.

--
Julien