Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.scheme Subject: Re: Re: Order of evaluation (was Re: evaluating () should be an error Message-ID: Date: 27 Mar 91 17:43:07 GMT References: <2977@kraftbus.cs.tu-berlin.de> <1991Mar26.155905.12906@daffy.cs.wisc.edu> <1991Mar26.224805.23381@cs. Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 43 In-Reply-To: manis@cs.ubc.ca's message of 26 Mar 91 22:48:05 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Vincent Manis says: In article kiran@copper.ucs.indiana.edu (Kiran Wagle) writes: >>Of course going to far in this direction might lead to specifying the >>evaluation order of arguments to procedures, and I don't think that would be >>good. >Why not? Because it can substantially impair the ability of a compiler to produce high-quality code. If a compiler is required to honour a particular order of evaluation, then compiling expressions which require most of the registers available will almost inevitably result in register spills, which then slow the code down. If a compiler can choose the order of evaluation, it can evaluate arguments in whatever order requires the fewest number of registers. I used to believe this argument; now I'm not so sure. Vincent posted more details, with an example, but the question is *how often* do such cases arise, and *how much* efficiency is wasted, if we insist on prescribed orders of evaluation? Are we talking measurements and results here, or conviction from a small number of examples? And how do we measure the time wasted because a programmer was misled by an implementation into expecting one order of evaluation, and then ported code to an implementation with a different order? Or the time wasted because, without a prescribed (and simple) order of evaluation, certain programming idioms become unavailable? [The argument that such idioms can lead to bad code is not persuasive; languages cannot prevent the writing of bad code; discouragement is better socially rather than at the language level [he said, having himself designed a language designed to prevent certain ``bad styles''!]]. As you can guess, I'm moving toward the prescibe-order-of-evaluation camp. Declarations and compiler inferences can deal with whanging the efficiency up for delivery. -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."