From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Depending on passing mechanism Date: 1997/10/19 Message-ID: #1/1 X-Deja-AN: 282016351 References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 877270140 12332 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-10-19T00:00:00+00:00 List-Id: << I have seen this particular claim challenged by several other compiler writers and no evidence was advanced to support it. Do you have evidence that leaving order of evaluation arbitrary is a performance enabler?>> It is always hard to get specific data across the complete spectrum of application domains. IBM comes closest to having the necessary trace data to do this kind of study, but that data is closely held. Obviously it is easy to construct examples where it can make a big difference. For example, consider: a + f(x) If you demand strict left to right evaluation in a language with unrestricted side effects, then the code has to load and save the value of A over the function call, just in case the function call disturbs the value of A. Certainly you will see an effect on the Specmarc if you constrain the order of evaluation. The real point is the following. We know that constrainining the order of evaluation will hurt the performance of some code. We know that constraining the order of evaluation will only affect code that uses side effects in a particularly nasty way. We don't want people writing code of that kind anyway. However, without banning side effects completely, a bad idea (*), we don't know any easy way of disallowing the "bad" side effects. We don't feel like damaging the efficiency of code just for the benefit of those who want to make nasty use of side effects. On the contrary, leaving the order of evaluation undefined will actively discourage the use of such side effects, a good thing! (*) everynow and then, someone wants to ban side effects completely in functions (some people even want to ban functions, if I remember right, one of Per Brinch Hanson's simplified Pascal-like languages went in this direction). However, this is a bad idea, which, once the full issues are examined, never gets more than a splinter of support. The trouble is that there are many legitimate uses for functions with side effects, an obvious example among many being the use of memo functions.