From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6AFDFBB81 for ; Fri, 9 Dec 2005 03:56:45 +0100 (CET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB92uh6g027107 for ; Fri, 9 Dec 2005 03:56:44 +0100 Received: from rosella (ppp33-4.lns1.syd2.internode.on.net [59.167.33.4] (may be forged)) by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id jB92uOgS006118; Fri, 9 Dec 2005 13:26:24 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] partial application warning unreliable? From: skaller To: Jacques Garrigue Cc: caml-list@yquem.inria.fr, malc@pulsesoft.com In-Reply-To: <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp> References: <20051208.121012.49167263.garrigue@math.nagoya-u.ac.jp> <1134092611.8940.57.camel@rosella> <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Date: Fri, 09 Dec 2005 13:56:23 +1100 Message-Id: <1134096983.8940.115.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4398F26B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 inference:01 generalizing:01 extern:01 silently:01 bug:01 ocaml:01 -warn-error:01 damien:01 orthogonal:01 -warn-error:01 inference:01 ocaml:01 wrote:01 sourceforge:01 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 On Fri, 2005-12-09 at 11:15 +0900, Jacques Garrigue wrote: > From: skaller > > The type of a statement is currently 'a, which is just > > plain wrong. The correct type is void, however unit > > will catch more errors than 'a. > > This behaviour has been known for long. > The trouble is that any change to this behaviour would not be > principal (from the type inference point of view). I'm not sure I understand that (what a principal type is .. ;( > That is, we might choose to instantiate 'a to unit when generalizing > the type of y, but actually #moo might be of type int, which we will > discover later, when applying it. As long as returning non-unit in a > statement grades only a warning, we cannot do that. > So, saying that the type of y above is wrong means that all statements > should be forced by type checking to return unit and nothing else. Yes. The only case I can think of where this would cause a problem is raising an exception -- since that is allowed ALSO in non-statement position. Of course some legacy code may break. And that is, IMHO, a good thing. Some C programmers even write: extern int f(int); (void) f(1); to make the casting away of the return value explicit, clearly believing that silently throwing away a return value is a bug in ISO C. In Ocaml we have ignore (f 1); if we really want side effects but not the return value. Its use should be mandatory. IMHO. > This is not the default, but this could indeed be done with > -warn-error S. Hmm .. When you see some code in a statement, you cannot report an error if the type is 'a, because it may later be specialised to type unit, and the error would then be premature. And secondly I asked: > If I turn off F, will I get S instead? and Damien replied: "Warnings are orthogonal: disabling F does not make you get more S warnings. It has no impact on S." so you'd need to -warn-error SF not just S ;( You surely wouldn't want -warn-error to actually change the way the inference engine worked! > Note that, for objects, there was before ocaml 3.05 a warning, turned > on only in -labels mode, that ensured that every method was known > before being called. This would have caught the above error. It is now > commented out :-( Is this particular problem specific to class methods? It seems to be a general typing problem to me, BUT, with objects you can call a method before seeing it, which you cannot do with ordinary functions. -- John Skaller Felix, successor to C++: http://felix.sf.net