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 KAA07663; Thu, 21 Aug 2003 10:58:15 +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 KAA29429 for ; Thu, 21 Aug 2003 10:58:14 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h7L8wCf17153 for ; Thu, 21 Aug 2003 10:58:13 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id RAA19355; Thu, 21 Aug 2003 17:58:08 +0900 (JST) To: ben@socialtools.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] does class polymorphism need to be so complicated? In-Reply-To: <3F448015.8090106@socialtools.net> References: <3F43E250.1040903@socialtools.net> <20030821092849B.garrigue@kurims.kyoto-u.ac.jp> <3F448015.8090106@socialtools.net> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030821175808V.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 21 Aug 2003 17:58:08 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jacques:01 caml-list:01 expressive:01 verbose:01 verbosity:01 beginners:01 generics:01 library's:01 api:01 implemented:01 superclass:01 workarounds:01 ocaml:01 caml:01 inherit:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Benjamin Geer > > 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. Sure. There's no intent to make it difficult. The idea is only that being a bit more verbose on a declaration that is hopefully made only once in a hierarchy is not that bad. The real problem actually is not verbosity, but the fact you have to understand that there can be two levels for polymorphism: the class or the method. I think that's not that immediate, and I don't want to bother beginners with that. We'll see the impact on Java programmers when they will get generics. > 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. Here there may be a deeper misunderstanding about the ocaml type system: if a subclass does not add methods to its superclass, its type does not change. That is, I would expect all connections to have the same type, and as a result there is no need for considering the more general #connection. > > 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. OK, there's also another way to do it, without inheritance. I just tried not to be confusing. class type printer = object method virtual print : #printable -> unit end class my_printer () = object (self : #printer) method print obj = ... end Looks a bit strange at first, but it does the work. > > 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. Might consider it. But its a rather big change in the language, so this requires some more study. Jacques ------------------- 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