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 92CD47ED5C for ; Fri, 3 Aug 2012 06:50:24 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=212.27.42.3; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=212.27.42.3; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp3-g21.free.fr) identity=helo; client-ip=212.27.42.3; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@smtp3-g21.free.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuICAJtXG1DUGyoDkGdsb2JhbABFuCIEgQEiAQEBAQkJDQcUAySCIAEBBScRQAEQCxgJFg8JAwIBAgFFBg0BBwEBiA29Q4tHNYZPA5VIhVuNEw X-IronPort-AV: E=Sophos;i="4.77,704,1336341600"; d="scan'208";a="152341254" Received: from smtp3-g21.free.fr ([212.27.42.3]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Aug 2012 06:50:23 +0200 Received: from [192.168.0.11] (unknown [78.192.0.38]) by smtp3-g21.free.fr (Postfix) with ESMTP id 4C982A61C9; Fri, 3 Aug 2012 06:50:19 +0200 (CEST) Message-ID: <501B588B.6040006@frisch.fr> Date: Fri, 03 Aug 2012 06:50:19 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ivan CC: caml-list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] type inference with classes 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. 1. The type-checker will never infer that a method is polymorphic. You need to tell it. object(this) method f = (this # g 1, this # g true) method g x = x end ===> object(this) method f = (this # g 1, this # g true) method g: 'a. 'a -> 'a = fun x -> x end 2. Same for labeled and optional arguments on methods, when the type for the method to be called is not known. class virtual c = object(this) method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2 end ===> class virtual c = object(this) method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2 method virtual g: x:int -> y:int -> int end (Note: this is really not specific to objects, a simple (fun g -> g ~x:1 ~y:2 + g ~y:1 ~x:2) has the same effect, but it's likely to hit you if you use virtual classes.) 3. When declaring classes, the inferred type must have no free variable. So while the expression "object method f x = x end" is allowed and is inferred to have a type "< f : 'a -> 'a >", the following class declaration is rejected: class c = object method f x = x end Depending on what you want to do, you can either force a specific type or make the class parametric: class c = object method f x : int = x end class ['a] c = object method f x : 'a = x end -- Alain On 8/3/2012 6:23 AM, Ivan wrote: > Hi! > > I've mentioned that in some cases ocaml can't infer type (or maybe it > can, but didn't want to...) of some objects. > Right to this moment, I've just do as ocaml wants - annotate a type and > move forward. But now I want to make things more consciously. The reason > is simple - sometimes ocaml infers types correctly and denotes a type > error in my code, but I, mistakenly thinking that it can't infer type of > object, loose my time in useless type annotating of different > identifiers. Or vice versa, the code is correct, except for some > undecidable object type, and I spend h^Wminutes in checking my code for > errors. > > So, I'would like to know the rules of type inference failures with > object types. In what cases an object type can and must be inferred, and > in what it must be annotated explicitly? > > Can someone share this arcane knowledge or, at least, point me at some > sources, explaining this issue? > > Thanks everybody in advance!