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 MAA04389 for caml-red; Tue, 10 Oct 2000 12:26:58 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA17483 for ; Mon, 9 Oct 2000 00:47:10 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e98Ml8125383 for ; Mon, 9 Oct 2000 00:47:09 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id PAA23558; Sun, 8 Oct 2000 15:47:04 -0700 (PDT) Date: Sun, 8 Oct 2000 15:47:04 -0700 (PDT) From: Brian Rogoff To: David =?iso-8859-1?q?Mentr=E9?= cc: caml-list@inria.fr Subject: Re: Undefined evaluation order In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: weis@pauillac.inria.fr On 8 Oct 2000, David [iso-8859-1] Mentr=E9 wrote: > Brian Rogoff writes: >=20 > > It is well known that OCaml has undefined evaluation orders and tha= t > > it uses right-to-left ordering. What is the rationale for that decision= ?=20 >=20 > It is linked to the way the bytecode is designed to optimize functions > evaluation. You'll find a detailed (and more accurate) explanation in > the following paper : >=20 > RT-0117 The ZINC experiment : an economical implementation of the ML > language - Xavier Leroy > http://www.inria.fr/RRRT/RT-0117.html Thanks David, that's exactly the kind of explanation I was looking for.=20 Interestingly, I had a discussion with my manager about this and we had slightly different views. I argued that evaluation order should be specified and that it should be left-to-right, which I hope everyone agrees is the most natural order. He argued that evaluation order should=20 be defined so that you can analyze programs, but that the order was irrelevant; he'd be happy with right-to-left if it were specified. For OCaml it appears that the perspective adopted is that the programmer must make the temporal dependencies explicit. The reason is for (bytecode) compi= ler=20 optimizations, but it is mentioned that this usually leads to clearer progr= ams.=20 I'm sure the bytecode compiler argument is valid, but not the code clarity = one,=20 since it sounds similar to an argument that having uninitialized variables = is=20 clearer since it forces you to make values explicit, and I don't believe th= at. -- Brian