From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA05284 for caml-red; Thu, 12 Oct 2000 13:46:20 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA02354 for ; Thu, 12 Oct 2000 10:36:30 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9C8aRX29367 for ; Thu, 12 Oct 2000 10:36:28 +0200 (MET DST) Received: from localhost (sansho.kurims.kyoto-u.ac.jp [130.54.16.90]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id RAA18049 for ; Thu, 12 Oct 2000 17:36:25 +0900 (JST) To: caml-list@inria.fr Subject: RE: Undefined evaluation order: define it for constructors ? In-Reply-To: Your message of "Wed, 11 Oct 2000 08:22:45 -0400" <706871B20764CD449DB0E8E3D81C4D43BFCA36@opus.cs.cornell.edu> References: <706871B20764CD449DB0E8E3D81C4D43BFCA36@opus.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Mew version 1.93 on Emacs 20.7 / Mule 4.0 (HANANOEN) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001012173521W.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 12 Oct 2000 17:35:21 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Sender: weis@pauillac.inria.fr Interesting that so many people would favour left-to-right order. First a tiny addition: there seems to be a belief that evaluation in ocaml is always right-to-left. This is true for ocaml2, but not always for ocaml3, since (even in classic mode) optional arguments can be passed in a different order. In such cases the compiler is free to choose any evaluation order, in practice this is right-to-left, but according to the type. # let f ?(x=0) ?(y=0) () = x + y;; val f : ?x:int -> ?y:int -> unit -> int = # f ~y:(print_int 2; 2) ~x:(print_int 3; 3) ();; 23- : int = 5 As Xavier wrote, this would be pretty easy to automatically convert the program as to provide strict left-to-right evaluation (according to the text), but this is another example of potential tiny innefficiency. Moreover, strict left-to-right order also means that the function must be evaluated first. For instance (f (f1 a1)) (f2 a2) would lead to (flattening all computations in sub-expressions) let x1 = f1 a1 in let f0 = f x1 in let x2 = f2 a2 in f0 x2 rather than the expected let x1 = f1 a1 in let x2 = f2 a2 in f x1 x2 In bytecode the second form is more efficient, since it often avoids the creation of a closure f0 (the binary application is detected at runtime). Another remark is that all the problems I see are due to unspecified evaluation order in value construction, not in function application. That is, tuples (Greg's example), records (Brian), and lists (Pierre, old List.map), where the syntax really suggests some sequencing. On the other hand, function application is more symmetrical, and one is less tempted by making assumptions about it. The only caml program I've seen depending on evaluation order in function application was by a friend of mine in Caml V3, about 10 years ago, and this was because he didn't know about ";" as a sequencer :-) Value construction and function application are distinguished syntactically in Caml, so they might be considered independently. I have a feeling that left-to-right order in value construction would not be that expensive, even in the bytecode interpreter. How is it? Regards, Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG