From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 226447ED5C for ; Fri, 3 Aug 2012 07:33:26 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAB5iG1CFBoIF/2dsb2JhbABFui2CIAEBBAEnEwkBNQIDCwsYHBI9GgYTiAcFBak3hDQBhlKIfQeLR4YkYJVLkA2CYQ X-IronPort-AV: E=Sophos;i="4.77,705,1336341600"; d="scan'208";a="152342974" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Aug 2012 07:32:58 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id C7C6C6309; Fri, 3 Aug 2012 14:32:55 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 9C35E394C; Fri, 3 Aug 2012 14:32:55 +0900 (JST) DomainKey-Signature: h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from tanpopo.home (AMontpellier-257-1-128-211.w92-143.abo.wanadoo.fr [92.143.195.211]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 9539F255D; Fri, 3 Aug 2012 14:32:53 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jacques Garrigue In-Reply-To: Date: Fri, 3 Aug 2012 07:32:49 +0200 Cc: Alain Frisch , caml-list Content-Transfer-Encoding: quoted-printable Message-Id: <60D24526-5521-4999-9894-5FDDBBA3B857@math.nagoya-u.ac.jp> References: <501B588B.6040006@frisch.fr> To: Ivan X-Mailer: Apple Mail (2.1084) Subject: Re: [Caml-list] type inference with classes On 2012/08/03, at 7:15, Ivan wrote: > On 3 August 2012 08:50, Alain Frisch wrote: > Hello, >=20 > I don't know if this covers all the case, but you need to keep in mind th= e following points. Feel free to add to the list. >=20 > Thanks for nice and structured answer!=20 >=20 > I'll try to expand it with my cases, but due to lack of comprehension the= y will not be so clear =3D) >=20 > 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.=20 >=20 > Starting from a simple case: >=20 > let reset_env_model state v =3D > let q =3D Queue.create () in > Queue.iter (fun p -> v#expand_row p) q >=20 > 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 >=20 > 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 co= mplains correctly. I agree =3D) I think that this case has some corresponde= nce 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 typ= e 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: >=20 > let reset_env_model state v =3D > let q =3D Queue.create () in > let m,_,_ =3D 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 >=20 > compiler cannot infer, that object p has type Gtk.tree_path, and with thi= s proposition imply, that the expand_row method has a type "Gtk.tree_path -= > unit"?=20 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=