From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id DAA08915 for caml-redistribution; Tue, 27 Jul 1999 03:47:15 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA23334 for ; Sat, 24 Jul 1999 14:17:16 +0200 (MET DST) Received: from iggy.triode.net.au (iggy.triode.net.au [203.63.235.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id OAA25690 for ; Sat, 24 Jul 1999 14:17:14 +0200 (MET DST) Received: from egret (pm1-28.triode.net.au [203.63.235.44]) by iggy.triode.net.au (8.9.3/8.8.8) with SMTP id WAA00322 for ; Sat, 24 Jul 1999 22:15:35 +1000 Message-Id: <3.0.6.32.19990722165137.00976500@mail.triode.net.au> X-Sender: skaller@mail.triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 22 Jul 1999 16:51:37 +1000 To: caml-list@inria.fr (OCAML) From: John Skaller Subject: Diagnostic bug? In-Reply-To: <199907181757.TAA31587@miss.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis The following code indicates an incorrect error diagnostic: type t = T;; let rec g (x:int) = (let (aT:t) = f x in ()) and f x : unit = ();; Line 5 characters 17-19: This expression has type unit but is here used with type t. The function f is explicitly declared with return type unit, and clearly returns the unit value: there is no error in f, and certainly the () is _not_ being used 'here' with type t. The error may be considered to be in the call of f, in the function g, or it may be considered to be in the explicit declaration of the return type of f, which clashes with the infered return type, or even in the whole of f, but it cannot be in the body of f: f is internally consistent. In my actual code, I got an error in a 5000 character expression, and it took three days to figure out the error wasn't in that expression at all. I can guess how the problem arises in the inference algorithm, but now I can't figure out a policy for tracking down type errors (since they can no longer be trusted). I found previously that adding explicit types helped isolate errors, but in this case it didn't. ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia