From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA08746; Thu, 21 Aug 2003 10:21:17 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA10189 for ; Thu, 21 Aug 2003 10:21:15 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h7L8LEf12676 for ; Thu, 21 Aug 2003 10:21:15 +0200 (MET DST) Received: by rabelais.socialtools.net (Postfix, from userid 108) id 10DD623311; Thu, 21 Aug 2003 09:21:14 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id A2D472330E; Thu, 21 Aug 2003 09:21:12 +0100 (BST) Message-ID: <3F448015.8090106@socialtools.net> Date: Thu, 21 Aug 2003 09:17:25 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] does class polymorphism need to be so complicated? References: <3F43E250.1040903@socialtools.net> <20030821092849B.garrigue@kurims.kyoto-u.ac.jp> In-Reply-To: <20030821092849B.garrigue@kurims.kyoto-u.ac.jp> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG autolearn=ham version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 expressive:01 library's:01 api:01 implemented:01 workarounds:01 recursion:01 caml:01 inherit:01 garrigue:01 rec:01 polymorphic:01 syntax:02 unit:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue wrote: > [explanation of issues concerning method polymorphism] Thank you for explaining this. > To speak truly, the current syntax is based on the assumption that you > won't define often polymorphic methods, and that defining them is a > work for library designers, not for the average end user. I think that one of the things that would improve life a great deal, for people wanting to write applications in Caml, would be the existence of many more libraries. Unfortunately, I think languages become popular not mainly because of how expressive they are, but because of the libraries available in them. Therefore, in order to help Caml become more widely used, it would be a good idea to make things as easy as possible for library authors. (That's actually why I came to this list; I want to write libraries in Caml, to make it more generally useful for writing applications.) Moreover, a library user needs to handle the library's own polymorphism. For example, suppose there were a Caml API for accessing databases, and that this API consisted entirely of class types, intended to be implemented by Caml 'drivers' for different databases. The library user would get a #connection; the class implementing #connection would be determined by the driver (and would never be known by the library user). In this way, the user could switch to a different database by switching to a different driver, without having to change any application code. In order to pass around this #connection object within the application, the library user would have to write polymorphic methods. > This also means that you have a number of workarounds hiding this > heavy syntax to the end user, even when he has to define such a > method. > > For instance you could be provided a virtual class printer: > > class virtual printer : object > method virtual print : #printable -> unit > method ... > end > > Then you would use it as > > class my_printer () = object > inherit printer > method print obj = ... > end That's somewhat better, but it means that every class must be derived from a virtual base, even when there's no other reason for it. > P.S. Having a lighter syntax for polymorphic methods might be a good > idea. But since we must keep it explicit enough, the improvement would > be quite limited. The best I can think of is something like: > method 'a. print (obj : #printable as 'a) = ... > Maybe a bit better, but also more complicated to handle. I think that would definitely be an improvement. > An advantage of such a syntax is that it could also be used in normal > "let rec" to provide polymorphic recursion. That would be a big advantage in my view. Ben ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners