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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id EEDF3BB84 for ; Fri, 20 Jun 2008 15:39:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsBAExQW0jAXQImiGdsb2JhbACBW5EJAQEBDyCccw X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="12351736" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 Jun 2008 15:39:38 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m5KDdcHQ031558 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 20 Jun 2008 15:39:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAAExQW0hTkhUImmdsb2JhbACBW5EJAQEBAQEIBQgHEQOccA X-IronPort-AV: E=Sophos;i="4.27,679,1204498800"; d="scan'208";a="14172797" Received: from smtp.dslgb.com (HELO cht-smtp-002.bulldogdsl.com) ([83.146.21.8]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 Jun 2008 15:39:38 +0200 Received: by cht-smtp-002.bulldogdsl.com (Postfix, from userid 1002) id CC8401E4202; Fri, 20 Jun 2008 14:39:37 +0100 (BST) Received: from [192.168.123.191] (host-84-9-232-148.dslgb.com [84.9.232.148]) by cht-smtp-002.bulldogdsl.com (Postfix) with ESMTP id 75BEE1E413D; Fri, 20 Jun 2008 14:39:32 +0100 (BST) Message-ID: <485BB314.2080405@ed.ac.uk> Date: Fri, 20 Jun 2008 14:39:32 +0100 From: Jeremy Yallop User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Mark Shinwell Cc: caml-list@inria.fr Subject: Re: [Caml-list] surprising type error with labels References: <485AD6A3.7060606@ed.ac.uk> <20080620125336.GN30596@janestcapital.com> In-Reply-To: <20080620125336.GN30596@janestcapital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 485BB31A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; shinwell:01 compiler:01 interacts:01 inference:01 inference:01 unify:01 polymorphic:01 wrote:01 caml-list:01 functions:01 surprising:01 surprising:01 algorithm:01 algorithm:01 behaviour:01 Mark Shinwell wrote: > 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. You'd have to distinguish between terms which refer to polymorphic functions and terms whose type is only partially known. I suspect it might be quite difficult to do that in a way that interacts satisfactorily with type inference. Even the current design has a rather unfortunate dependence on the particular order of execution of the type inference algorithm. For example, given a definition let h = fun ~x:() () -> () the following program is allowed let g f x = ([f; h], f x) whereas the following rather similar program is not let g f x = (f x, [f; h]) If the type inference algorithm sees `[f; h]' first then it gives f a fully-known labeled type and allows it to be applied without a label when it subsequently encounters `f x'. If it sees `f x' first then it assigns an unlabeled type to f, which subsequently fails to unify with the type of h. I agree that the current behaviour is surprising, but I'm not sure that it's easy to make it much less surprising, even if you're willing to give up some expressiveness. Jeremy.