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=1.6 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 5850DBB84 for ; Thu, 11 Dec 2008 01:52:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAHfzP0lIDtybimdsb2JhbACTDD4BAQEKCQwHDwWlDoEEjDUBAwEDgwODcw X-IronPort-AV: E=Sophos;i="4.33,749,1220220000"; d="scan'208";a="32485766" Received: from fg-out-1718.google.com ([72.14.220.155]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Dec 2008 01:52:50 +0100 Received: by fg-out-1718.google.com with SMTP id l27so354466fgb.43 for ; Wed, 10 Dec 2008 16:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8jEIqV/PrXDGiOpxu0LNB/FxaTx9elTxu6391eHrsR4=; b=ic8zC7K0ac5iQEK3igeJKIwjC1VY6HhRWN83hPTsJTWxOy5IegXKqnCM4I5KzHMfwQ u+tyXI06l5JNtwVScieIiwJreda0qQJXfgRMBJAptVLpp0Qvi7vmgs4iEDTUetXFoZQz Ag3szNneqE8Lv31kMZzvG9qvRdouLQISCUFUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KE9i9yFE5kYmiN+ewkS9SqzmYstr6OREoqAxOReAtMtfYR1WT88u8XLIKOMdriHTtK at8/TgQ0TQBWPARm8GVfDJzhYAooljy8e2h4xOZNNa/wSIZJXOF62v+Xgb7qANHvglyL vsBBfouAoSlaAL5uYXBGcJc/QYaIvEYEsIo7k= Received: by 10.86.31.18 with SMTP id e18mr959795fge.72.1228956769394; Wed, 10 Dec 2008 16:52:49 -0800 (PST) Received: by 10.86.99.18 with HTTP; Wed, 10 Dec 2008 16:52:49 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 00:52:49 +0000 From: "Conglun Yao" To: "Jacques GARRIGUE" Subject: Re: [Caml-list] How to handle try .... finally properly? Cc: caml-list@yquem.inria.fr In-Reply-To: <20081211.090934.68540743.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081211.090934.68540743.garrigue@math.nagoya-u.ac.jp> X-Spam: no; 0.00; curried:01 incorrectly:01 runtime:01 printf:01 storm:98 invoke:01 partial:01 compile:01 compile:01 caml-list:01 partially:02 parameter:02 parameter:02 checking:02 garrigue:03 > A usual workaround in such situations is to first partially apply your > function to the (n-1) first arguments, as this should cause no > side-effects. Since I suppose you are really talking about > > transform f x y > > you should rather write > > transform (f x) y > It indeed helps, forces to invoke function f (with two parameters) inside transform. We know how to use transform properly, passing a function with only one parameter or passing curried f with n-1 parameters. But what if we were providing a library, users still might use it incorrectly, thus it will cause a runtime error rather than compile time error. I know it's difficult and (even) impossible to do this kind of compile time checking, zip1, zip2, zip3, .... zip7, mentioned by blue storm, might be a better solution. Ask users to follow the convention, use zip1 if f has one parameter use zip2 if f has two parameters .... use zip7 if f has seven parameters OR transform only accepts function with one parameter, multiple parameters must be passed as a touple type like (a, b, c) > Note that this will not work properly if partial applications of f cause > side-effects (i.e. f is actually "fun x -> ...; fun y -> ..."). > This is pretty rare, but I believe this is the case for printf for > instance. > > Jacques Garrigue >