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 70946BB84 for ; Wed, 12 Jul 2006 02:35:10 +0200 (CEST) Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6C0Z8Ha019293 for ; Wed, 12 Jul 2006 02:35:09 +0200 Received: from localhost (nat00-c2 [172.16.60.194]) by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id k6C0YjRJ027479; Wed, 12 Jul 2006 09:34:45 +0900 (JST) Date: Wed, 12 Jul 2006 09:37:17 +0900 (JST) Message-Id: <20060712.093717.16034933.garrigue@math.nagoya-u.ac.jp> To: brogoff@speakeasy.net Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Polymorphic method question From: Jacques Garrigue In-Reply-To: References: <20060711.163207.72458365.garrigue@math.nagoya-u.ac.jp> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44B443BC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; downcasts:01 ocaml:01 downcasts:01 type-safety:01 ocaml:01 verbose:01 syntax:01 1.5:98 polymorphic:01 polymorphic:01 caml-list:01 abstract:01 typing:01 encode: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.4 required=5.0 tests=DNS_FROM_RFC_ABUSE autolearn=disabled version=3.0.3 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, > > 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. > > 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. I would not say that your Java version is more "typed". It is less so if you have downcasts! By the way, the Scala version I mentioned uses no downcast, but cannot accomodate polymorphic methods (at least in the mentioned paper.) So there seems to be a tension between guaranteed type-safety and immutability. The point is that to solve it cleanly, one has to use type parameters in an abstract type. OCaml is able to do it, but I agree that this is rather verbose. [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. Jacques Garrigue