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 5588EBDC5 for ; Sat, 20 Aug 2005 00:22:12 +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 j7JMMB4m023637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Aug 2005 00:22:12 +0200 Received: from mail (mail [192.168.69.23]) by mail.dravanet.hu (8.13.4/8.13.4/Debian-3) with SMTP id j7JMMAFK027713 for ; Sat, 20 Aug 2005 00:22:11 +0200 Message-ID: <43065B83.6050503@dravanet.hu> Date: Sat, 20 Aug 2005 00:21:55 +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: Parameter evaluation order Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43065B93.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; unspecified:01 ocaml:01 unspecified:01 ocaml:01 ocamlopt:01 simpler:01 logical:01 passing:01 newline:02 newline:02 closure:02 closure:02 parameter:02 parameter:02 parameters:02 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 I was recently thinking about parameter evaluation order and how come it is unspecified in OCaml. Maybe this was already discussed here, but I do not recall it and cannot find it, either. Do not get me wrong, I do not have an unsurmontable problem with unspecified parameter evaluation ordering, and in a world full of languages with similar disclaimers I could not even have a problem. Also, side effects in parameters is just ugly. So the current shape of the language is fine with me. But I do think that currying + strictness + side-effects => left-to-right evaluation order. That is because a multi-parameter function application should be functionally equivalent to a closure taking the first (== leftmost) parameter and returning a closure which takes the second parameter etc. while parameters should be evaluated before passing, as per strictness. Consider the following code: ==== ordertest.ml ===== let f a b c d = () let () = let ff1 = f (print_string "1") in let ff2 = ff1 (print_string "2") in let ff3 = ff2 (print_string "3") in ff3 (print_string "4"); print_newline () let () = let f2 = f (print_string "1") (print_string "2") in f2 (print_string "3") (print_string "4") ; print_newline () let () = f (print_string "1") (print_string "2") (print_string "3") (print_string "4"); print_newline () ============== The three let ()'s should be functionally equivalent, and yet they are not: --------------------- $ ocaml ordertest.ml 1234 2143 4321 --------------------- ocamlopt creates a different outcome, but that is well known: the last line reads 1234. Of course, if this kind of logic was applied, labels and FFI's would be difficult to handle. Probably even enrichment of the type system with 'has side effect' and forbidding the use of expressions with such types in parameters would be simpler than that, not that I advocate either solution. I do not say we should have left-to-right evaluation order, only that it would be more logical. Am I wrong? M-