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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-05 23:41:09 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 06 Feb 2004 01:41:06 -0600 Date: Fri, 06 Feb 2004 02:41:06 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions References: <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075482385.142744@master.nyc.kbcfp.com> <1075732402.294581@master.nyc.kbcfp.com> <1075741279.952497@master.nyc.kbcfp.com> <16nu1099ekujjbpe9dqvs3noi9sdcfja6e@4ax.com> <1075817212.745748@master.nyc.kbcfp.com> <1075824683.769215@master.nyc.kbcfp.com> <1075851506.238480@master.nyc.kbcfp.com> <4020C947.81A6D703@0.0> <1075907239.138068@master.nyc.kbcfp.com> <402232E9.3EE15B4B@0.0> <1075987360.225622@master.nyc.kbcfp.com> <1075995793.145904@master.nyc.kbcfp.com> In-Reply-To: <1075995793.145904@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-LmH1TC5Iu2hJc047ygzi5UuXR7Yl7WmysOV35zWjHJukmVnBt7FytNx6xhSkMw2JA5LvdD7ek3KRXAn!TQ4YDmENWUzph76HJP+LlBJ4SpvtHFWMTzFu08QKXV0w0I+P2sdxt5NiW2LD0w== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5272 Date: 2004-02-06T02:41:06-05:00 List-Id: Hyman Rosen wrote: > Think about it - if you write > s := Sin(x) + Cos(y) > Ada requires that both arguments are evaluated, but doesn't specify the > order. Yet, with a pragma Pure in place, Ada need not evaluate the operands > each time in a loop, but can hoist the calculations out, as you say. Why > would specifying the order change this? That may be why you keep butting your head against a brick wall. If Ada said that in an equation like: s := Sin(1-x) + Cos(y); that the terms had to be evaluated left to right, that would say you couldn't evaluate Cos(y) before Sin(1-x) whether or not they were declared Pure. Ada does allow compilers to combine calls to Pure functions, and if that is not okay, don't declare them Pure. But that doesn't say that Pure functions can't have side effects. It just changes what a compiler is allowed to do with Pure functions. In fact, right now on the ARG list we are discussing a fix to 10.2.1 Elaboration Control which defines pragma Pure and pragma Preelaborate. There are some new features in Ada 0Y that require some wording changes, and we want them to be as restrictive as necessary, but no stricter. In that discussion we have discussed exactly this issue. (A Pure subprogram call can be eliminated, and if the subprogam has side-effects, well the programmer was warned. No different from some other effects of optimizing compilers. But note that what users have been warned about is that marking a unit as Pure may allow the optimizer to eliminate some calls. The compilers are not allowed to call the function somewhere that it wouldn't be called otherwise. The compiler must insure that a Pure function that would never be called in the canonical order is never called in the order the compiler selects. And if two Pure functions have side effects, and both are called, the side effects must happen in the right order. So the new rule that you are proposing would severly limit some very useful optimizations, unless you had exceptions for Pure functions, and predefined operators, and static expressions, and... Well you get the picture. Soon you have more exceptions than case that are constrained by the rule, and all to insure that functions with side-effects are called in a single canonical order. We prefer to have one easily understood set of rules. Unfortunately in some useful cases these rules work out to "if you really want to be sure, install a block with an exception handler." But this is based on twenty years of experience. Users at all levels don't want strict execution orders in most cases, but they all seem to want very good optimization. Also note incidently that what some users really do care about, and which has raised entirely too much discussion for something that will never be changed, is short-circut expression evaluation. I don't know how many requests I have seen in various forms for redefining 'or' to mean 'or else' and 'and' to mean 'and then'. (The proposals for the current meanings of 'and' and 'or' have lots of different syntax suggestions associated with them.) But the real unalterable answer is NO! (Or maybe something more forceful.) There is too much existing code that depends on the current rules and the cost of revising that code is totally out of proportion to the potential savings--which I don't even think exist. The compiler can use short circut forms if the expression after 'and' or 'if' is marked Pure or a static expression, or only involves predefined expressions, etc. (See the similar list above, which is what brought it to mind. ;-) So the only cases where the proposed rule change would make a difference are exactly those cases that would have to be revised in existing code. And when you check on why the request was made, it often resulted from an error message at compile time. The message can always be eliminated by changing the 'and' to 'and then' or the 'or' to 'or else'. But in practice the programmer really has to think to be sure that is the right change. It is the required thinking that seems to generate the revision requests. If 'and then' and 'or else' were the defaults then they wouldn't need to think during compilation, and they could wait for an exception at run-time. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush