From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 097C5BB9C for ; Sat, 10 Dec 2005 01:49:33 +0100 (CET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jBA0nUx9031741 for ; Sat, 10 Dec 2005 01:49:32 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id jBA0nDtf021687; Sat, 10 Dec 2005 09:49:13 +0900 (JST) Date: Sat, 10 Dec 2005 09:49:08 +0900 (JST) Message-Id: <20051210.094908.32150993.garrigue@math.nagoya-u.ac.jp> To: malc@pulsesoft.com Cc: skaller@users.sourceforge.net, caml-list@yquem.inria.fr Subject: Re: [Caml-list] partial application warning unreliable? From: Jacques Garrigue In-Reply-To: References: <1134092611.8940.57.camel@rosella> <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 439A261A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 malc:01 malc:01 pulsesoft:01 annotation:01 inference:01 polymorphic:01 partial:01 avoids:01 jacques:01 jacques:01 defined:01 warnings:02 objects:02 garrigue:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: malc > I gather all this means that the only "safe" way to call a unit method > on an implictily typed object is via: > > let () = o#moo in ... Yes, but only if the type of o is unknown. If o itself was defined by a let statement, or there was a type annotation let f (o : c) = ... then the warnings will work properly (fortunately.) Personally, I annotate almost all objects received as function arguments. It may be seen as defeating the purpose of type inference, but this produces better error messages, and avoids the above problem. It is also necessary with polymorphic methods or optional arguments. Jacques Garrigue