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 74E07BB84 for ; Tue, 11 Jul 2006 07:22:49 +0200 (CEST) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6B5Ml1K015287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 07:22:48 +0200 Received: (qmail 17658 invoked from network); 11 Jul 2006 05:22:42 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Jul 2006 05:22:42 -0000 Date: Mon, 10 Jul 2006 22:22:42 -0700 (PDT) From: brogoff To: Jacques Garrigue Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Polymorphic method question In-Reply-To: <20060711.110916.22502254.garrigue@math.nagoya-u.ac.jp> Message-ID: References: <20060711.110916.22502254.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 44B335A7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; foobar:01 inference:01 inference:01 foobar:01 ocaml:01 verbose:01 verbose:01 ocaml:01 1.5:98 wrote:01 polymorphic:01 polymorphic:01 caml-list:01 extensible:01 speakeasy: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.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 On Tue, 11 Jul 2006, Jacques Garrigue wrote: > From: brogoff > > Because bar is not yet completely defined when you use it in foobar. > This is all related with parameter constraint inference: we don't know > yet wether bar's parameter is really polymorphic or is constraint (e.g. > 'a = 'b * 'c). > Note that the problem does not occur with direct type definitions, as > constraint inference is not done in that case (this is one of the > reasons you cannot combine type and class definitions.) > > # type 'a bar = < get: 'a > and foobar = < f : 'a. 'a bar -> 'a >;; > type 'a bar = < get : 'a > > and foobar = < f : 'a. 'a bar -> 'a > > > The only way to solve this problem would be to remove parameter > constraint inference from classes. It would certainly break some > programs, so this seems difficult. That's too bad, as it seems the class based OO version of the extensible visitor is fairly straightforward in OCaml except for this counterintuitive gotcha. What would have to be done to fix the broken programs? It may be worth considering. > By the way, if you're ready to define your types first, then you > can do this properly. In the more realistic example I sent along after, you'll see that this solution is not really pleasing. You'd need to create a parallel type hierarchy to match your class hierarchy, which is too verbose. All this because we must have inference, which is supposed to make things less verbose. Ironic, isn't it? ;-) I have seen the new private rows stuff, which is very nice, but all of these solutions IMO are way too complex to be considered satisfactory. I'll see if the Java 1.5 approach actually works (I used some Pizza code to do the OCaml implementation) because that was quite straightforward. I'd prefer approaches that I can explain with a little hand waving. I think type theorists often forget that there are a few programmers still who don't have PhDs in type theory and will look at such solutions and conclude that OCaml is not for them ;-). -- Brian