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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 7EF52BC6B for ; Wed, 27 Jun 2007 12:24:55 +0200 (CEST) Received: from orion.metastack.com (no-dns-yet.demon.co.uk [80.177.38.218] (may be forged)) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5RAOsbW000945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Jun 2007 12:24:55 +0200 Received: from treble (cpc2-cmbg6-0-0-cust535.cmbg.cable.ntl.com [81.107.34.24]) (authenticated bits=0) by orion.metastack.com (8.13.4/8.13.3) with ESMTP id l5RAHdWm017014 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 27 Jun 2007 11:17:39 +0100 From: "David Allsopp" To: References: <20070627100004.9E0DABC73@yquem.inria.fr> Subject: Re: [Caml-list] let rec and polymorphic functions Date: Wed, 27 Jun 2007 11:24:53 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <001801c7b8a5$672a2b80$6a7ba8c0@treble> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace4oQLTnoxTdEYEQXeaegOfusdk5wAAcDXg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070627100004.9E0DABC73@yquem.inria.fr> X-Miltered: at concorde with ID 46823AF6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ad-hoc:01 polymorphism:01 recursion:01 val:01 val:01 type-checker:01 o'caml:01 bool:01 printf:01 ad-hoc:01 specifier:01 ocaml:01 ocaml:01 run-time:01 higher-order:01 > There are many problems with this. Google for ad-hoc polymorphism, > polymorphic recursion and generic printing. > > On Wednesday 27 June 2007 09:40:31 David Allsopp wrote: > > out "TEST"; > > val out : string -> unit > > > out "%d" 0; > > val out : format -> int -> unit The type-checker doesn't see that surely? Surely on that expression it sees out : string -> int -> unit?? Note that changing the sequence to out "%b" true; out "%d" 0; and removing the out "TEST" still causes problems - although O'Caml manages to infer the [format4] first argument for [out], it fixes the first parameter of the [format4] as being [bool -> unit] and so prevents [out] from being used with anything other than a single "%b" argument and hence gives a type error on the next application. > As printf is ad-hoc polymorphic, you must supply the format specifier > immediately and OCaml will generate a custom printer for you. OCaml does > not use run-time types so you cannot have a generic print function: you > must specific print functions for each of your (possibly higher-order) > types. Yes, except that what's odd to me is that the type-checker doesn't behave as the manual says it ought to with [let rec]. BUT... > Also, recursive calls ossify the function to a monomorphic type, so you > cannot do polymorphic recursion in OCaml. There are workaround using > recursive modules or objects but I don't think this is what you want here. That does explain it - which I didn't know. Consider this which is also broken (and simpler because it has nothing to do with the ad-hoc polymorphism of printf) let rec id x = x and _ = id 0 in id (); (* *** *) id 1;; Gives a type error for *** because id is already inferred as int -> int because of the monomorphic nature of the recursive definition. This is over-guarded but I never got an answer on a previous post as to why. The equivalent SML does type polymorphically: let fun id x = x val _ = id 0 in id (); id 1 end; Incidentally, it's lucky that this is polymorphic in SML because all function definitions are recursive IIRC. But no-one posted an explanation as to why there's this difference in the let construct between the two flavours of ML :( David