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 140297ED5C for ; Fri, 3 Aug 2012 07:15:29 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of lambda.q.q@gmail.com) identity=pra; client-ip=209.85.220.194; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="lambda.q.q@gmail.com"; x-sender="lambda.q.q@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of lambda.q.q@gmail.com designates 209.85.220.194 as permitted sender) identity=mailfrom; client-ip=209.85.220.194; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="lambda.q.q@gmail.com"; x-sender="lambda.q.q@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vc0-f194.google.com) identity=helo; client-ip=209.85.220.194; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="lambda.q.q@gmail.com"; x-sender="postmaster@mail-vc0-f194.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8EAFJdG1DRVdzCZWdsb2JhbABFuR4IIg0KCgcUKYIgAQEBAwESAhMZATgBAwELAQUFBAc7IhIBBQEcBhMIGodcAwYGnkUJA48UhVwnDYlIAQUMizuHBAOIR4Uph1iOMD6BVIIv X-IronPort-AV: E=Sophos;i="4.77,705,1336341600"; d="scan'208,217";a="152342372" Received: from mail-vc0-f194.google.com ([209.85.220.194]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Aug 2012 07:15:28 +0200 Received: by vcbfy7 with SMTP id fy7so51491vcb.9 for ; Thu, 02 Aug 2012 22:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+LoHqjpYtnY9jb/RYHleDFgdobpZmS3ZYj0iIp2gAxE=; b=P/cdvRrLcrU4l5+zippBERYo+RXCf2+UChdETVYL2bSSkQWSCpZYGwIARauMWF5Vgt OYyHhY+2nfuFqHGmFUv5eFtX193KvF7Y21s7XxB69bqOuM8iJ99msYPcoh6FBmMyDrR6 nQNMvMgad1vOCgSRHANAO3jrPVAQMqJ/nYoU41zlzKrtIQFh/OqcVwfnHAghH9IJBED1 VmflTY2KjxrZJHcWcm++Qzft8bZnLgmdqwqKmSh9zVf3bOxSWjRoU8XR/tHKQLdqvODU 9xpM5ezDg9I7Y8WVuw8potyULGnWdS6YcavlwVDIffvec7H+dNrR2bqNb8e9sbB+WaJ4 VjtQ== MIME-Version: 1.0 Received: by 10.58.182.35 with SMTP id eb3mr371337vec.42.1343970926781; Thu, 02 Aug 2012 22:15:26 -0700 (PDT) Sender: lambda.q.q@gmail.com Received: by 10.58.218.35 with HTTP; Thu, 2 Aug 2012 22:15:26 -0700 (PDT) In-Reply-To: <501B588B.6040006@frisch.fr> References: <501B588B.6040006@frisch.fr> Date: Fri, 3 Aug 2012 09:15:26 +0400 X-Google-Sender-Auth: n9iD_XTlX8nVwfeF8oV3ErASw_U Message-ID: From: Ivan To: Alain Frisch Cc: caml-list Content-Type: multipart/alternative; boundary=047d7b6d9792ade69504c6559d90 Subject: Re: [Caml-list] type inference with classes --047d7b6d9792ade69504c6559d90 Content-Type: text/plain; charset=ISO-8859-1 On 3 August 2012 08:50, Alain Frisch 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. 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"? --047d7b6d9792ade69504c6559d90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3 August 2012 08:50, Alain Frisch=A0<alain@frisch.fr>=A0= wrote:
Hello,

I don't know if this covers all the case, but you need to= keep in mind the following points. =A0Feel free to add to the list.

Thanks for nice and structured answer!= =A0

I'll try to expand it with my cases, but due to lac= k of comprehension they will not be so clear =3D)

= 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 som= e object and type system tries to infer what objects it can accept.=A0

Starting from a =A0simple case:

let = reset_env_model state v =3D
=A0=A0let q =3D Queue.create () in
=A0=A0Queue.iter (fun p -> v#expand_row p) q
produces an error:
=A0=A0 =A0This expression has type GTree.view<= /div>
=A0=A0 =A0 =A0 but an expression was expected of type < e= xpand_row : 'a -> unit; .. >
=A0=A0 =A0 =A0 Types for m= ethod expand_row are incompatible

because expand_row method of type GTree.view has = type:
=A0=A0 expand_row : Gtk.tree_path -> unit;
I think, that compiler have a reason to refuse this code: funct= ion wants a method, that can take an=A0arbitrary=A0value of type 'a, bu= t I pass a method that has a covariant type=A0Gtk.tree_path in position lef= t to arrow. So he complains correctly. I agree =3D) I think that this case = has some=A0correspondence=A0with your =A0case #1.

But, why in the following code:

let reset_env_model state v =3D
=A0=A0let q =3D Queue.crea= te () in
=A0=A0let m,_,_ =3D State.env_model state in
= =A0=A0m#foreach (fun p _ -> if v#row_expanded p then Queue.push p q; fal= se);
=A0=A0set_env_model state v;
=A0=A0Queue.iter (fun p -> v= #expand_row p) q

compiler cannot infer, that objec= t p has type Gtk.tree_path, and with this proposition imply, that the expan= d_row method has a type "Gtk.tree_path -> unit"?=A0
--047d7b6d9792ade69504c6559d90--