Re: [Caml-list] What about polymorphic methods

[Alessandro Baretta <alex@baretta.com>]

Jacques Garrigue wrote:
> 
> Indeed, iterators are one of the major reasons to have polymorphic
> methods in ocaml (the other one being implicit subtyping of
> arguments). They are already in CVS, and will be present in ocaml
> 3.05.
> 
> 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 -> ...


Hello Jacques and Caml riders,

I am very excited about the possibilities offered by the 
polymorphic methods of Ocaml 3.04+13, which I have recently 
downloaded and built from the CVS site. Please, allow me one 
more question on this matter.

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

An analogous error message would be given for right_iter, 
with reference to 'c, if the explicit generalization were 
used for left_iter.

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.

I think that coding a method whose type contains an unbound 
type variable, implicitly means that the programmer desires 
that type variable to be generalized. Since the compiler is 
able to determine what type variables "ought" to be 
generalized, why does it not perform and "implicit" 
generalization, rather than requiring an "explicit" 
generalization in the code?

I hope I am making some sense to somebody. Do excuse me if I 
have used improper terminology, but I am not a professional 
of functional languages and type theory.

Regards,
Alex Baretta

-------------------
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