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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id B0641BB84 for ; Tue, 11 Jul 2006 06:56:58 +0200 (CEST) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6B4uuUW011431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 06:56:58 +0200 Received: (qmail 13011 invoked from network); 11 Jul 2006 04:56:52 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Jul 2006 04:56:52 -0000 Date: Mon, 10 Jul 2006 21:56:52 -0700 (PDT) From: brogoff To: skaller Cc: caml-list@yquem.inria.fr, Richard Jones Subject: Re: [Caml-list] Polymorphic method question In-Reply-To: <1152584645.5206.46.camel@rosella.wigram> Message-ID: References: <20060710200508.GA18988@furbychan.cocan.org> <1152584645.5206.46.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 44B32F98.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; polymorphism:01 recursive:01 recursive:01 variants:01 recursion:01 recursions:01 vastly:01 faux:01 ocaml:01 ocaml's:01 suboptimal:01 syntax:01 inference:01 polymorphism:01 2006:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 On Tue, 11 Jul 2006, skaller wrote: > 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: See the thread that Richard referenced, and go to Jacques Garrigue's final post. There he writes: "Inside mutually recursive definitions of classes, parameters cannot be used polymorphically" That's the problem, isn't it? > 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 ..] That's surely annoying, but it's a different problem I think. > > 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. If you look at the faux OCaml code I provided, I believe the intent is clear, forgiving OCaml's, ummm, suboptimal syntax. I could code it up in Java 1.5 (maybe I should, just to make sure it works!) and since Java doesn't do parameter inference it may all work fine. > 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). The code for this in Java 1.5 is quite clear, syntactically. It's a bit tricky to get it all right, of course, but someone smarter than me already figured it out, I just want to implement the trick in my language of choice, which is not Java. > Unfortunately .. the easiest kind of solution is to write > a code generator in Python or Perl .. this kind of polymorphism > is not exactly desirable .. ;( No, I think you're missing the point of the "exercise" here. I'm not looking for a code generator, but an OO approach to building extensible visitors with precise static type checking. -- Brian