Re: [Caml-list] What about polymorphic methods

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Alessandro Baretta <alex@baretta.com>
> > 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