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 MAA13764; Mon, 10 Jun 2002 12:15:24 +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 MAA13760 for ; Mon, 10 Jun 2002 12:15:24 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5AAFHb07041 for ; Mon, 10 Jun 2002 12:15:22 +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.3/3.7W) with ESMTP id TAA28594; Mon, 10 Jun 2002 19:13:55 +0900 (JST) To: alex@baretta.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] What about polymorphic methods In-Reply-To: <3D01D3D3.701@baretta.com> References: <3CEF08ED.80407@baretta.com> <20020525125530P.garrigue@kurims.kyoto-u.ac.jp> <3D01D3D3.701@baretta.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020610191355R.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 10 Jun 2002 19:13:55 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Alessandro Baretta > > With the CVS version, you would have to write > > > > method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ... > > method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ... > > I do not understand why I have to declare 'b explicitly as a > "polymorphic" type variable for the two iterators. If I omit > the explicit generalization of 'b in my bidirectional list > class, the compiler yields the following error message: > > Some type variables are unbound in this type: > > class ['a] bidi_list : > > 'a list -> > > object > > val first : 'a bidi > > val last : 'a bidi > > method head : 'a bidi > > method left_iter : ('a -> 'b) -> 'b list > > method right_iter : ('a -> 'c) -> 'c list > > method tail : 'a bidi > > end > > The method left_iter has type ('a -> 'b) -> 'b list where > > 'b is unbound > > To me, this means that the type checker is able to correctly > determine the type of the class and of the polymorphic > methods. It simply refuses to generalize unbound type > variables without "written consent" from the programmer. There are two problems. One is theoretical: while implicit polymorphisation would work in many cases, it would not work in all cases. For instance, it does not work with polymorphic recursion: you would be only able to call inherited methods recursively. And it's not always clear whether the extra polymorphism was really intended: as polymorphic methods are not compatible with non-polymorphic ones, choosing between the two is clearly not principal. Requiring an annotation is on the safe side. On the practical side, class typing relies heavily on unification. This is neat: you can view inheritance as unifying with #c, from a typing point of view. This means that once you've assumed a non-polymorphic type (as you usually do to type recursion), you cannot go back to the polymorphic one (does not unify). This problem is only technical, and it also means you cannot refine method types in subclasses, so I'm no sure it will stay forever. Also, I have a feeling that classes in caml are an advanced feature. They can help you modelling easy to use libraries, or building big programs. In both cases, the extra verbosity is only on the producer side, while the consumer can profit from the extra comfort at very little cost. For instance with my scheme you don't need annotations in subclasses. So I hope these annotations will not mean lots of trouble. Yet, this is a new feature, and experience will tell us. In particular if beginners start writing visitor patterns all around, this may not work that well. Jacques Garrigue ------------------- 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