From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 34BACBC68 for ; Sun, 29 Oct 2006 06:08:26 +0100 (CET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k9T58NfJ003956 for ; Sun, 29 Oct 2006 06:08:25 +0100 Received: from rosella (ppp229-164.lns3.syd7.internode.on.net [59.167.229.164]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k9T57sxa091400; Sun, 29 Oct 2006 15:37:54 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] weird type behavior From: skaller To: Kirill Cc: Richard Jones , caml-list@yquem.inria.fr In-Reply-To: <1162084356.23148.64.camel@nfnl> References: <1162050549.23148.26.camel@nfnl> <20061028161226.GA28781@furbychan.cocan.org> <20061028161506.GA2596@furbychan.cocan.org> <1162083950.23148.58.camel@nfnl> <1162084356.23148.64.camel@nfnl> Content-Type: text/plain Date: Sun, 29 Oct 2006 16:07:54 +1100 Message-Id: <1162098474.7104.81.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45443747.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; 0200,:01 polymorphism:01 ocaml:01 inference:01 ocaml:01 run-time:01 inference:01 annotation:01 notation:01 'int':01 quantifier:01 1.2:98 1.2:98 'poly':98 sourceforge:01 On Sun, 2006-10-29 at 03:12 +0200, Kirill wrote: > Hi, > > Unfortunately, I wasn't able to infer, how to solve my problem from the > FAQ, nor from other sources. I can see that partial application somehow > interferes with polymorphism, and partial application does look > necessary for my task. Does it mean it's completely impossible in OCaml? > Or is there still some way to overcome the problem? A limitation of Hindley-Milner type inference: you cannot pass a polymorphic function to a function. The Ocaml run-time supports this fine, but the type inference engine is only able to cope with universal quantification. [To be clear: the Ocaml *type system* allows it but the inference engine cannot infer it and there's currently no way to override the inference engine: a coercion would be unsafe, and an annotation on the argument is a constraint applied after inference so doesn't help] So when you DO pass a polymorphic function to a function, it is specialised (monomorphised) inside the function, depending on its use. For example: # let g x = x,x in let f g x y = g x, g y in f g 1 1.2;; This expression has type float but is here used with type int # let g x = x,x in g 1, g 1.2;; - : (int * int) * (float * float) = ((1, 1), (1.2, 1.2)) The function g really is polymorphic here, but not inside f. The notation '_a generally means this monormorphised version of type variable 'a: it happens to be 'int' in the first example, so the system prints that instead: '_a means 'some ground type we don't know' as opposed to 'a which means 'any type'. Ocaml will allow you to pass a polymorphic function provided you wrap it in a class or record: # type poly = { h : 'a . 'a -> 'a * 'a };; type poly = { h : 'a. 'a -> 'a * 'a; } You can see here the quantifier 'a . is localised to the record field. Note the type 'poly' is in fact quite monomorphic -- there's no type parameter, one of the fields just happens to be a polymorphic function. # let g x = x,x in let f k x y = k.h x, k.h y in f {h=g} 1 1.2;; - : (int * int) * (float * float) = ((1, 1), (1.2, 1.2)) -- John Skaller Felix, successor to C++: http://felix.sf.net