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 E0428BB84 for ; Wed, 12 Jul 2006 21:26:26 +0200 (CEST) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6CJQO9b025306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Jul 2006 21:26:26 +0200 Received: (qmail 30260 invoked from network); 12 Jul 2006 19:26:21 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Jul 2006 19:26:21 -0000 Date: Wed, 12 Jul 2006 12:26:21 -0700 (PDT) From: brogoff To: Jacques Garrigue Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Polymorphic method question In-Reply-To: <20060712.093717.16034933.garrigue@math.nagoya-u.ac.jp> Message-ID: References: <20060711.163207.72458365.garrigue@math.nagoya-u.ac.jp> <20060712.093717.16034933.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 44B54CE0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; downcasts:01 downcasts:01 syntax:01 clos:01 variants:01 ocaml:01 1.5:98 wrote:01 polymorphic:01 polymorphic:01 caml-list:01 encode:01 speakeasy:01 speakeasy:01 argument: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 Wed, 12 Jul 2006, Jacques Garrigue wrote: > From: brogoff > > > 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. > > Well, if you're ready to have downcasts in your code... > But then, I'd hoped that there would be some trick I could figure out to remove the downcast, but it's essentially to overcome the lack of covariant method arguments (the visitor argument of the visited class) so yes it's a flaw in the approach. > I would not say that your Java version is more "typed". It is less so > if you have downcasts! Fair enough. However, the "typecase" that's being performed has only one branch, and is localized to the extending class, so as such crimes go, it's more like vandalism than arson. > [About having to write the type hierarchy by hand] > > 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. > > Indeed. At times I wonder whether it would not be better to have a > syntax to do this with types. Or maybe not to infer parameter > constraints for class types, as they are required for extensibility. I think if we're going to do OO in an ML like language, I think it is probably more promising to consider a system like Dylan or CLOS. But that's a huge change, for a brand new language. I'd rather have a simpler language, with more powerful records, variants and module system. I usually use classes in OCaml as records anyways. -- Brian