From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
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 D19F2BC69
	for <caml-list@yquem.inria.fr>; Mon, 16 Jul 2007 11:01:02 +0200 (CEST)
Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5])
	by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6G910mC021708
	for <caml-list@yquem.inria.fr>; Mon, 16 Jul 2007 11:01:02 +0200
Received: from localhost (rabbit-172 [172.16.254.254])
	by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id l6G90k9M028952;
	Mon, 16 Jul 2007 18:00:46 +0900 (JST)
Date: Mon, 16 Jul 2007 18:00:46 +0900 (JST)
Message-Id: <20070716.180046.194240538.garrigue@math.nagoya-u.ac.jp>
To: colanderman@gmail.com
Cc: rajb@rice.edu, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Recursive class+type definitions
From: Jacques GARRIGUE <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <875c7e070707151927t529c3e2anb2dc9a5c5bf634fe@mail.gmail.com>
References: <11E0700C-4331-42AB-88F1-E6BD21D72F78@rice.edu>
	<875c7e070707151927t529c3e2anb2dc9a5c5bf634fe@mail.gmail.com>
X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Miltered: at concorde with ID 469B33CC.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; recursive:01 recursive:01 verbose:01 annotations:01 sig:01 getx:01 plist:01 plist:01 rec:01 signatures:01 caml-list:01 interfaces:01 pair:01 modules:02 modules:02 

From: "Chris King" <colanderman@gmail.com>

> You can get the exact behavior you want using a pair of recursive
> modules (see the "Language Extensions" section of the manual), one for
> each of mypoint and mypointlist, but it's a lot more verbose (since
> recursive modules require you to explicity give their signatures).

I would think that one recursive module is sufficient.
Note also that, as this virtual class has no concrete methods, it
could just be defined as a class type (just means you can only use it
in interfaces and type annotations.) Then there is no code
duplication.

module rec Mypoint : sig
  class type p =
     object
       method getx : float
       method getlist : Mypoint.plist
     end
  type plist = Empty | Cons of (p * Mypoint.plist)
end = Mypoint

Jacques Garrigue