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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 42930BC0A for ; Mon, 19 Feb 2007 10:12:55 +0100 (CET) Received: from postar.fmf.uni-lj.si (vega.fmf.uni-lj.si [193.2.67.45]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1J9CsR3010447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Feb 2007 10:12:55 +0100 Received: from localhost (unknown [192.168.5.1]) by postar.fmf.uni-lj.si (Postfix) with ESMTP id 4B17B10BC4A; Mon, 19 Feb 2007 10:12:52 +0100 (CET) X-Virus-Scanned: amavisd-new at spam.fmf.uni-lj.si Received: from postar.fmf.uni-lj.si ([192.168.5.5]) by localhost (spam.fmf.uni-lj.si [192.168.5.1]) (amavisd-new, port 10024) with ESMTP id bqM2yKkwRykw; Mon, 19 Feb 2007 10:27:04 +0100 (CET) Received: from [193.2.67.88] (unknown [193.2.67.88]) by postar.fmf.uni-lj.si (Postfix) with ESMTP id EB71B104CE5; Mon, 19 Feb 2007 10:12:51 +0100 (CET) Message-ID: <45D96AFB.50904@fmf.uni-lj.si> Date: Mon, 19 Feb 2007 10:16:43 +0100 From: Andrej Bauer Reply-To: Andrej.Bauer@andrej.com User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: caml-list@inria.fr Cc: christian konrad Subject: Re: [Caml-list] Question about try.. with References: <45D79283.8000101@in.tum.de> <20070218.181909.64993949.garrigue@math.nagoya-u.ac.jp> <45D8EB3E.7010002@in.tum.de> In-Reply-To: <45D8EB3E.7010002@in.tum.de> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45D96A16.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; andrej:01 andrej:01 recursion:01 recursion:01 infile:01 infile:01 wrote:01 rec:01 caml-list:01 binary:01 tail:01 tail:01 undefined:01 argument:02 defined:02 christian konrad wrote: > But that seams really strange not to have a strictly defined order of > evaluation. Isn't that really bad if one would like to do some tail > recursion to get it compiled without recursion but as a loop? Undefined order of evaluation allows more optimization. Arguably, it may be confusing for the programmer (especially one who is used to relying on order of evaluation of arguments to a function call--a rather dangerous practice). But your remark about tail recursion is mistaken, i.e., you are suggesting that a call to a function inside an argument to another function might be tail-recursive, which is clearly impossible. In your example, you had let rec readIn() = .... (input_line infile) ^ readIn() .... Here we have arguments "input_line infile" and "readIn()" to the binary operation ^. It does not matter what the order of evaluation of the arguments is: readIn cannot be tail-recursive under any order, since the last thing that needs to happen is ^. Best regards, Andrej