From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id B1C9CBDD8 for ; Fri, 26 Aug 2005 14:09:17 +0200 (CEST) Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.68]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7QC9HT7009972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 26 Aug 2005 14:09:17 +0200 Received: from [192.168.144.2] (84-4-33-159.adslgp.cegetel.net [84.4.33.159]) by smtp.cegetel.net (Postfix) with ESMTP id 788483185AC; Fri, 26 Aug 2005 14:09:14 +0200 (CEST) Message-ID: <430F0669.6050103@univ-savoie.fr> Date: Fri, 26 Aug 2005 14:09:13 +0200 From: Christophe Raffalli User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Parameter evaluation order References: <43065B83.6050503@dravanet.hu> <430CE193.9000805@univ-savoie.fr> <430EE6A1.9040705@univ-savoie.fr> <200508261110.41183.jon@ffconsultancy.com> In-Reply-To: <200508261110.41183.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 430F066D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 christophe:01 raffalli:01 univ-savoie:01 caml-list:01 semicolons:01 ocaml's:01 grammar:01 endline:01 endline:01 unspecified:01 variants:01 syntax:01 semantics: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.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 Jon Harrop a écrit : > On Friday 26 August 2005 10:53, Christophe Raffalli wrote: > >>This looks strange, because the semicolumn is used both to specify order >>evaluation left-to-right in sequence and right-to-left in record. > > > I haven't checked but it is probably undefined, rather than right-to-left in > records. > > Semicolons are used in many places in OCaml's grammar. Would you expect the > members of a list literal to be evaluated left-to-right, for example? > > # [print_endline "1"; print_endline "2"];; > 2 > 1 > - : unit list = [(); ()] > yes I would ... In fact, after though, the only place where evalauation order should be unspecified or better, specified right-to-left is function application and all other case (tuple, variants (and therefore list), should be left-to-right. Let me explain: - why function should be right-to-left: because the syntax is somehow wrong, the argument should come first ! A good way to think about it is when you write the operationnal semantics of call-by-value if v is a value then (fun x -> t) v evaluates t[x:=v] in this sentence we are looking at v first. Another point: if you use a stack (either to define the semantics or to implement), the left most argument should be on the top of the stack and therefore pushed last. Why are most language left-to-right: because nobody wanted to reverse the notation of function aplpication :-) (and if you think, the standard notation for numbers should also be reversed ... and whe should read from right to left, which is what we do when we do an addition with paper and pencil) - why other contructor (tuple, records, variants) should be left-to-right: because this is the most natural thing to do, and in fact there is no semantical reason to choose one evaluation order or another (except for variant constructor if you consider that they are function like others). (except that they are people around the world that writes right-to-left or top-to-bottom ... what are the camlp4 guys doing for this poor people ;-) - why should the evaluation order be specified: this is needed if you want to formally reason about programs ... as far as I know. I had like to find a system where I can prove programs in call-by-value whatever evaluation order they use ... but I do not know how to do that, without proving programs for all the possible evaluation order as soon as the argument have side effect which is too much. - Yes, this is a pity since you may want the compiler to interleave the code of the various arguments to fill the pileline. But I think doing this when the code has no side effect is enough (like with arithmetic expression in a + b + c, d + e + f).