From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D0FBDBDDA for ; Fri, 26 Aug 2005 19:54:05 +0200 (CEST) Received: from mail.dravanet.hu (mail.dravanet.hu [212.40.69.7]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7QHs5ge008523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Aug 2005 19:54:05 +0200 Received: from mail (mail [192.168.69.23]) by mail.dravanet.hu (8.13.4/8.13.4/Debian-3) with SMTP id j7QHs3fe023967 for ; Fri, 26 Aug 2005 19:54:04 +0200 Message-ID: <430F572E.9050506@dravanet.hu> Date: Fri, 26 Aug 2005 19:53:50 +0200 From: =?ISO-8859-1?Q?=22M=E1rk_S=2E_Zolt=E1n=22?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Parameter evaluation order References: <43065B83.6050503@dravanet.hu> <4306F415.60806@inria.fr> In-Reply-To: <4306F415.60806@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 430F573D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 posts:01 frisch:01 binary:01 semantically:01 model:01 implicitly:01 curried:01 damien:01 ocaml's:01 unspecified:01 ocaml:01 recursion:01 wrote:01 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 First of all, thank you for your answers. I thought a bit about this stuff - took a while. For reasons I am too embarrassed to explain, I prefer to answer a number of posts in one reply. Alain Frisch wrote: > >It is, but your conclusion about left-to-right evaluation order is >wrong. It's just that the binary application operator evaluates first >its second argument (the function's argument), then its first argument >(the functional value), and finally applies the function to the >argument. An application (e1 e2) is semantically equivalent to: (let y >= e2 in let x = e1 in x y). Hence you get right-to-left evaluation order >(but this is not specified). > >-- Alain > > I think I have to retract my equation completely: right now I do not see how *any* evaluation order would be implied by currying + strictness + side effects at all. Alain, in your model right-to-left evaluation is a consequence of defining (e1 e2) as you do; if it was defined to be (let x = e1 in let y = e2 in x y), we would have left-to-right evaluation. So the evaluation order is introduced by the definition of the functional application, not by strictness, currying etc. I still wonder why did I implicitly assume this latter definition for function application. It seemed so straightforward, and it is also the order in which application of curried functions is usually explained (the explanation proceeds this way, it does not ever say that the actual ordering is also left-to-right). Sorry, guys. Damien Doligez wrote: > The problem (and historical reason for OCaml's unspecified order) is > that > > currying + side-effects + left-to-right evaluation order => inefficiency That line of reasoning is fine with me, as I would not make use of a declared parameter evaluation order anyway, while I constantly rely on the performance of OCaml. Whoever relies on parameter evaluation order is probably capable of committing other hideous crimes, too. brogoff wrote: >It's a fun topic to chat about, but if you were allowed one change in the >language, surely this wouldn't be it? :-) > Absolutely so. Tail recursion modulo cons is more important. Regards M-