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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 85F4FBB84 for ; Fri, 20 Jun 2008 14:53:43 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAMBFW0jAXQImiGdsb2JhbACSZAEBAQ8gnF8 X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="14168662" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 Jun 2008 14:53:41 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m5KCregX029405 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 20 Jun 2008 14:53:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIAAFxEW0hCm3xrnWdsb2JhbACSZAEBAQEBCA0HnGQ X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="14301200" Received: from www.janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Jun 2008 14:53:39 +0200 Received: from qsmtp.delacy.com [38.105.200.250] by janestcapital.com with ESMTP (SMTPD-9.10) id A8510744; Fri, 20 Jun 2008 08:53:37 -0400 Received: from nyc-qws-011.delacy.com ([172.25.131.111] helo=nyc-qws-011) by qsmtp.delacy.com with smtp (Exim 4.62) (envelope-from ) id 1K9g7U-0004MH-U8; Fri, 20 Jun 2008 08:53:37 -0400 Received: by nyc-qws-011 (sSMTP sendmail emulation); Fri, 20 Jun 2008 08:53:36 -0400 From: "Mark Shinwell" Date: Fri, 20 Jun 2008 08:53:36 -0400 To: Jeremy Yallop Cc: caml-list@inria.fr Subject: Re: [Caml-list] surprising type error with labels Message-ID: <20080620125336.GN30596@janestcapital.com> References: <485AD6A3.7060606@ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485AD6A3.7060606@ed.ac.uk> User-Agent: Mutt/1.4.2.1i X-Miltered: at discorde with ID 485BA854.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; shinwell:01 0100,:01 listlabels:01 listlabels:01 bool:01 bool:01 compiler:01 4.1:98 wrote:01 wrote:01 caml-list:01 functions:01 surprising:01 int:01 int:01 On Thu, Jun 19, 2008 at 10:58:59PM +0100, Jeremy Yallop wrote: > Jake Donham wrote: > >Why does > > > > ListLabels.find (fun _ -> true) [];; > > > >produce > > > > Characters 16-31: > > ListLabels.find (fun _ -> true) [];; > > ^^^^^^^^^^^^^^^ > > This expression should not be a function, the expected type is > > ('a -> 'b) list > > > >I thought the rule was that "if an application is total, labels may be > >omitted." (4.1 in the manual). (I was trying to do module List = > >ListLabels at the top of a file.) Thanks, > > Applications of functions whose return types are type variables are > never considered total, since it's possible to pass extra arguments if > the type variable is instantiated to a function type. For example, > ListLabels.find has type > > f:('a -> bool) -> 'a list -> 'a > > If the type variable is instantiated to `bool -> bool', say, then you > can pass more than two arguments: > > ListLabels.find ~f:(fun f -> f false) [not] false I'm not really sure that this behaviour (which is highly non-obvious from the error message) is to do with applying future unlabelled arguments. As far as I can see it's probably this way so you can apply future _labelled_ arguments, meaning you can write things like: # ListLabels.find [] (fun x -> x);; - : f:((('a -> 'a) -> 'b) -> bool) -> 'b = and also: # ListLabels.find ~f:(fun (f:(z:int -> int)) -> true) ~z:42 [fun ~z -> 1];; - : int = 1 (note that the ~z:42 has been commuted with the list). This seems kinda cool, but the code is somewhat obfuscated, and error messages are potentially confusing as Jake witnessed. Is there any theoretical reason why the compiler couldn't just deem applications of the form given by the original poster as total, even though it results in the loss of some expressibility? Perhaps it would be easier to improve the error messages in that case... or perhaps it just results in too little expressibility for some reason. Mark