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 0F938BB84 for ; Tue, 11 Jul 2006 20:20:38 +0200 (CEST) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6BIKZB8006770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 20:20:37 +0200 Received: (qmail 29384 invoked from network); 11 Jul 2006 18:20:32 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Jul 2006 18:20:32 -0000 Date: Tue, 11 Jul 2006 11:20:32 -0700 (PDT) From: brogoff To: Jacques Garrigue Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Polymorphic method question In-Reply-To: <20060711.163207.72458365.garrigue@math.nagoya-u.ac.jp> Message-ID: References: <20060711.110916.22502254.garrigue@math.nagoya-u.ac.jp> <20060711.163207.72458365.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 44B3EBF3.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; verbose:01 inference:01 verbose:01 syntax:01 ocaml:01 surprising:01 expr:01 odersky:01 reverted:01 ocaml:01 1.5:98 wrote:01 wrote:01 polymorphic:01 polymorphic: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 > > > 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'm not so sure about verbosity. Type syntax is pretty compact :-) But we have to repeat the information from the type in a later class, which seems redundant. Also, there's no way I know of to build object types from other object types, similar to the way I can combine polymorphic variant types. I haven't tried to encode it yet, maybe I'll try later, but I don't see how it can be made to work. > I'm sure you need some tricks to make it work in Java 1.5 too. The nastiest one for Caml is a downcast, when you want to extend the data the new class must call the extended visitor in its visit method. But Java supports this, so no big deal. Also, Java generics require that primitive types be wrapped, a mild annoyance. That's about it. Way easier than my attempts in OCaml, even though I don't use Java much at all. OK, to be fair, the original paper uses some Java variant (Pizza?) so maybe that's not too surprising. I wrote the code and it compiled, but I haven't tested it. > I don't have the code in mind. > I agree that the solution I posted is not too simple, but I don't > think this is PhD level. Actually it's not much worse than the visitor > pattern. What is hard is understanding why you have to do all this > extra work, not using the pattern itself. Sure, I exaggerated for affect, but I think the comparison with Java for this problem is telling. I'm reminded of something David MacQueen wrote in his paper "Should ML be Object Oriented" where he says in essence that the functional core of ML is lightweight and understandable but that OO (from the static typing POV) is surprisingly subtle and complex. > Note that, if you are ready to use a slightly less functional > approach, where the result is extracted from the visitor afterwards, > then typing is no problem. > This code is based on http://cristal.inria.fr/~remy/work/expr/ > It is strictly equivalent to Odersky&Zenger's Scala version. > (Actually this kind of code is one reason we reverted to sharing of > instance variables in 3.10) That's probably the right way to proceed, namely to eliminate the problem by eliminating the polymorphic methods. Too bad, the Java solution is both more functional, and more "typed". One of those rare cases for me where I feel that the Java solution is more elegant than the OCaml one. -- Brian