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 p2JKUHRt027945 for ; Sat, 19 Mar 2011 21:30:17 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkCAOuuhE3RVdY0kGdsb2JhbACERKEpCBQBAQEBCQkNBxQEIWyHWp8VigY8gh+EJS+IWwEBAwWBIoNFdwSMZ4RDhDw6 X-IronPort-AV: E=Sophos;i="4.63,211,1299452400"; d="scan'208";a="103095082" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Mar 2011 21:30:12 +0100 Received: by bwj24 with SMTP id 24so5430513bwj.39 for ; Sat, 19 Mar 2011 13:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=bESnoEBytxwQGNIenjMQkUwOqTWjgzQZrlzkxS/3kVI=; b=JvTAKHi8AorWTnxlBHiYMxxi4yJ4HyExKCpaG0WyOus5xRjFzkyadViHYs6s1t+lym r3wJLjtpCfWVqiL1YwejNQ2XcC2YMNiik3H0/fmS10JRf0KaS9kyCDccFUXap+t1OPsL TLYme0sS1bfXkPQg6mDyBTu1Symtqru0QCeo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=nmAaeL2WoOa5lB2Vpx9zptAqBekP1J3U3EmGfyaeHcbd++1eTnbR5NZFGvifseGq3e xD8upujjVuibAPm2Lj1Ou2udBJfEruBUpeLKWRJdivMVq/8hUkMsub3odRCw+G7805oj S9sP3yU8WA6K+pQ1wkLiEWpslf6+hbRPi++ts= Received: by 10.204.83.88 with SMTP id e24mr2130918bkl.78.1300566611586; Sat, 19 Mar 2011 13:30:11 -0700 (PDT) Received: from cloudy.localnet ([85.69.95.49]) by mx.google.com with ESMTPS id q18sm3136409bka.15.2011.03.19.13.30.08 (version=SSLv3 cipher=OTHER); Sat, 19 Mar 2011 13:30:09 -0700 (PDT) From: Raphael Proust To: Guillaume Yziquel Date: Sat, 19 Mar 2011 21:36:24 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37-ARCH; KDE/4.6.1; i686; ; ) Cc: caml-list@yquem.inria.fr References: <201103191648.40345.raphlalou@gmail.com> <201103192020.36314.raphlalou@gmail.com> <20110319194533.GT20405@localhost> In-Reply-To: <20110319194533.GT20405@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Message-Id: <201103192136.24416.raphlalou@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p2JKUHRt027945 Subject: Re: [Caml-list] Recursive Parametric class type Typing Le samedi 19 mars 2011 20:45:33, Guillaume Yziquel a écrit : > Le Saturday 19 Mar 2011 à 20:20:36 (+0100), Raphael Proust a écrit : > > Le samedi 19 mars 2011 18:48:03, Guillaume Yziquel a écrit : > > > Le Saturday 19 Mar 2011 à 16:48:40 (+0100), Raphael Proust a écrit : > > > > Hi list, > > > > > > > > Trying to bind a javascript library for js_of_ocaml, I encountered > > > > the following pattern (here drastically simplified): > > > > > > > > class type ['t] c = > > > > object > > > > method plus: 't -> unit > > > > method minus: unit -> 't > > > > method container: unit -> container > > > > end > > > > and container = > > > > object > > > > method int: unit -> int c > > > > method string: unit -> string c > > > > end > > > > > > > > The following error is raised at compile time: > > > > Error: This type string should be an instance of type int > > > > > > > > In the use case: > > > > - instead of [int] and [string] there are six different [class > > > > type]s; - [classe type]s have more methods; and > > > > - there are additional recursive [class type]s > > > > > > > > Why is there such a limitation on the types? Is there a work around > > > > that wouldn't induce (too much) code duplication? > > > > > > The reason why there is this behaviour is unification within the 'and' > > > declaration. method int says that 't in ['t] c is of type int, > > > therefore it should also be an int c in method string instead of a > > > string c. > > > > It makes sens… > > > > > Workaround: Use recursive modules. They are a solution for keeping > > > recursion while breaking type unification. Something in the taste of: > > > > > > yziquel@seldon:~$ ocaml > > > […] > > > > Because I want both [t] and [e] available (in fact there are 4 recursive > > classes I want available), I made several recursive modules. Beside > > having each type written twice, it still had a typing error: > > > > Error: In the definition of Paper.paper, type > > > > Svg.circle_attr Elem.element > > should be > > 'a Elem.element > > Noticed it too. Do not know where that comes from. > > > […] > > A perhaps more natural way would be to use object types. Something like > > type t = private < z : int e; u : string e > > > is easier to declare, and easier to declare recursively. Drawbacks: you > still have issues when you want to declare the meat of your classes; and > doesn't work well with ocamldoc. Well my classes don't have meat: they only serve as cast from js objects (sort of…). I used this approach (save the [private] inducing an Error about types not having a row variable) and it works. I just have to duplicate a few things due to inheritance not being available. Thanks, -- ______________ Raphaël Proust