From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 CA0E3BB84 for ; Tue, 11 Jul 2006 04:24:30 +0200 (CEST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6B2OSIa006815 for ; Tue, 11 Jul 2006 04:24:29 +0200 Received: from rosella (ppp44-64.lns2.syd6.internode.on.net [59.167.44.64]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k6B2O51A003910; Tue, 11 Jul 2006 11:54:06 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Polymorphic method question From: skaller To: brogoff Cc: Richard Jones , caml-list@yquem.inria.fr In-Reply-To: References: <20060710200508.GA18988@furbychan.cocan.org> Content-Type: text/plain Date: Tue, 11 Jul 2006 12:24:05 +1000 Message-Id: <1152584645.5206.46.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44B30BDC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; polymorphism:01 recursive:01 variants:01 recursion:01 recursions:01 vastly:01 polymorphism:01 metaocaml:01 2006:98 wrote:01 sourceforge:01 polymorphic:01 incremental:01 caml-list:01 encode:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Mon, 2006-07-10 at 16:25 -0700, brogoff wrote: > The restriction on polymorphism in mutually recursive class > definitions makes the idea unworkable. Any possibility that restriction will be > lifted? I don't believe there is such a restriction: the problem is when you introduce other types such as variants which must recurse with class types, there's no support for type class t1 = .. and t2 = [`X ..] etc. The solution, using extra parameters and open recursion, followed by closure of the recursions, works but is vastly too messy to encode by hand if there are more than a couple of parameters needed. This really does need to be automated in the special case where you're only opening the types so you can later close them. In general, for incremental type building, you need to retain the open types.. and it isn't clear if there's any way to make it tractable (syntactically I mean). Unfortunately .. the easiest kind of solution is to write a code generator in Python or Perl .. this kind of polymorphism is not exactly desirable .. ;( Can MetaOcaml can handle this better? -- John Skaller Felix, successor to C++: http://felix.sf.net