Re: [Caml-list] type inference with classes

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

On 2012/08/03, at 7:15, Ivan wrote:

> On 3 August 2012 08:50, Alain Frisch <alain@frisch.fr> wrote:
> Hello,
> 
> I don't know if this covers all the case, but you need to keep in mind the following points.  Feel free to add to the list.
> 
> Thanks for nice and structured answer! 
> 
> I'll try to expand it with my cases, but due to lack of comprehension they will not be so clear =)
> 
> So the setup is follows: I have a class with a type explicitly specified in mli file. No inference on it's methods. And a function, that takes some object and type system tries to infer what objects it can accept. 
> 
> Starting from a  simple case:
> 
> let reset_env_model state v =
>   let q = Queue.create () in
>   Queue.iter (fun p -> v#expand_row p) q
> 
> produces an error:
>     This expression has type GTree.view
>        but an expression was expected of type < expand_row : 'a -> unit; .. >
>        Types for method expand_row are incompatible
> 
> because expand_row method of type GTree.view has type:
>    expand_row : Gtk.tree_path -> unit;

> I think, that compiler have a reason to refuse this code: function wants a method, that can take an arbitrary value of type 'a, but I pass a method that has a covariant type Gtk.tree_path in position left to arrow. So he complains correctly. I agree =) I think that this case has some correspondence with your  case #1.


Your assumption is wrong. A function never "requires" polymorphism from an argument.
It may require a polymorphic method, but only if the type of this argument is given explicitly.

The fact is that, at least in lablgtk-2.14.2 (the current version), the type is

      expand_row : ?all:bool -> Gtk.tree_path -> unit

So this enters the second category of methods with optional arguments.

> But, why in the following code:
> 
> let reset_env_model state v =
>   let q = Queue.create () in
>   let m,_,_ = State.env_model state in
>   m#foreach (fun p _ -> if v#row_expanded p then Queue.push p q; false);
>   set_env_model state v;
>   Queue.iter (fun p -> v#expand_row p) q
> 
> compiler cannot infer, that object p has type Gtk.tree_path, and with this proposition imply, that the expand_row method has a type "Gtk.tree_path -> unit"? 


This is exactly the same problem as above.

In some situations it may be a good idea to use the -principal flag, to get more regular behavior from the type checker with respect to required type annotations.

	Jacques Garrigue