From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0F10dT6026006
	for <caml-list@sympa-roc.inria.fr>; Sat, 15 Jan 2011 02:00:39 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwBACOAME3RVdW2kGdsb2JhbACZYIp2CBUBAQEBCQkMBxEEIKM0jBCEVIcIAQEDBYVKBIRphi2EDYU2
X-IronPort-AV: E=Sophos;i="4.60,325,1291590000"; 
   d="scan'208";a="95467182"
Received: from mail-yx0-f182.google.com ([209.85.213.182])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2011 02:00:34 +0100
Received: by yxh35 with SMTP id 35so1390582yxh.27
        for <caml-list@inria.fr>; Fri, 14 Jan 2011 17:00:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:sender:subject:mime-version:content-type:from
         :in-reply-to:date:cc:content-transfer-encoding:message-id:references
         :to:x-mailer;
        bh=JZnuuJMdNIqBGXoKEpYsL8Z8BByel1fG9wU0yQpDosY=;
        b=cXJo9JKaoT1LvGU15YiZc+wY5DnQnGSoKZslPJuR5LzxgxzA4MwmbC2BQESUFfGG5F
         2aNsKjWg2p8HI592wVouuMOp+pZ0MSqZ2hcZyGjoz3aX6btmKjzPCV2EG+mOoGJh8nBF
         E8u98Lezb6ajepbTOn4mDRhqsLL2snNIIzXeI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=TuS/N+zpW1kcsYt8tTnrQOL3H7xV1MCskI3HYcOkSKas21k4MGI/VgntGcSFbJfBoz
         MKlU/h1yK+k7BLSaFm0b9mR4lv5+eGOr7W9/YUL2JK9Pj0c8MQiicYcdt9jcUMRKScyA
         XSWidfV+Ns1qfJDYJY86AS7prRQJkHbKYcbTg=
Received: by 10.90.118.2 with SMTP id q2mr1991895agc.11.1295053233496;
        Fri, 14 Jan 2011 17:00:33 -0800 (PST)
Received: from tanpopo.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157])
        by mx.google.com with ESMTPS id f10sm2050127anh.5.2011.01.14.17.00.31
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 14 Jan 2011 17:00:32 -0800 (PST)
Sender: Jacques Garrigue <jacques.garrigue@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <C7AAD554-4DA5-4811-8AAA-84E14E46C31D@philou.ch>
Date: Sat, 15 Jan 2011 10:00:28 +0900
Cc: caml-list@inria.fr
Message-Id: <F31806A7-4DDD-4DCB-9D7E-299A04EABD72@gmail.com>
References: <C7AAD554-4DA5-4811-8AAA-84E14E46C31D@philou.ch>
To: Philippe Strauss <philou@philou.ch>
X-Mailer: Apple Mail (2.1082)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p0F10dT6026006
Subject: Re: [Caml-list] writing a not too simple parametrized class interface

On 2011/01/15, at 2:46, Philippe Strauss wrote:

> Hello ocaml users,
> 
> I'm in a fight with hindley-milner when writing a .mli for a set of classes which implement a pipeline pattern, for processing either float array or Complex.t array, caching the result in each pipeline element.
> 
> each element type (class) inherit from node_virt_t, which use parametrized type for circumventing around the lack of "c++" like method overloading, for having the ability to use either float array or Complex.t array as input/output data type.
> 
> the whole things works perfectly, but the .mli seems not easy to write.
> uncomment class node_spectrum_t or class node_mag_t and you'll get:
> 
> File "nodes.mli", line 68, characters 30-45:
> Error: The type parameter Complex.t array
>       does not meet its constraint: it should be float array
> 
> which I don't understand.

[...]
The problem can be tracked down to this single line:

> class virtual ['b, 'c] node_virt_t : ('a, 'b) node_virt_t -> parameters_t -> int -> int -> [...]

Object types are allowed to be recursive, but they are restricted to _regular_ types,
where recursive occurences have identical type parameters.
In particular, this means that in the above line, ('a,'b) node_virt_t and ('b,'c) node_virt_t
must have the same parameters, i.e. that 'a = 'b and 'b = 'c, i.e. all your types
end up being identical.

But in your particular case, the recursion seems unnecessary.
You could write:

class type ['b, 'c] node_t :
   object
       method get_id : int -> int
       method private inc_id : int -> unit
       method virtual ptyp : unit -> node_parameters_t
       method virtual process : 'b -> 'c
       method private pstore : int -> int * int * 'c
       method get : int -> int * int * 'c
end

class virtual ['b, 'c] node_virt_t : ('a, 'b) node_t -> parameters_t -> int -> int ->
   object
       val previous : ('a, 'b) node_t
       val parms : parameters_t
       val hres : (int * int * string, 'c) Hashtbl.t
       val mutable id : int array
       inherit ['b,'c] node_t
end

Hopefully, this should solve your typing problem.

Of course, you might also consider whether you really need to use objects for that.
Closures are usually enough for cacheing, and they do not involve the advanced
aspects of the type system.

Jacques Garrigue