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=-0.9 required=5.0 tests=BAYES_00,FROM_NUMERIC_TLD autolearn=no 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 04:14:23 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!priapus.visi.com!orange.octanews.net!news-out.visi.com!petbe.visi.com!news.octanews.net!uunet!ash.uu.net!lore.csc.com!baen1673807.greenlnk.net!baen1673807!not-for-mail From: Stuart Palin Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Thu, 05 Feb 2004 12:11:22 +0000 Organization: Computer Sciences Corporation Message-ID: <402232E9.3EE15B4B@0.0> 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> NNTP-Posting-Host: 20.44.240.32 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: lore.csc.com 1075983257 6518 20.44.240.32 (5 Feb 2004 12:14:17 GMT) X-Complaints-To: abuse@news.csc.com NNTP-Posting-Date: Thu, 5 Feb 2004 12:14:17 +0000 (UTC) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en X-Original-NNTP-Posting-Host: rc2966.rochstr.gmav.gecm.com X-Original-Trace: 5 Feb 2004 12:09:51 GMT, rc2966.rochstr.gmav.gecm.com Xref: archiver1.google.com comp.lang.ada:5245 Date: 2004-02-05T12:11:22+00:00 List-Id: Hyman Rosen wrote: > > Stuart Palin wrote: > > But, it also creates an opportunity for 'smart compilers' to optimize. > > Notice that if an expression has only one possible value regardless of > evaluation order then the compiler can evaluate it in any order it wants, > and with the current evaluation rules, it is unwise to write expressions > that have more than one possible value based on evaluation order. So no > correct existing programs necessarily need to be pessimized by fixing > evaluation order. But the premise in many of your other postings in this thread seems to be concerned with resolving the case where the expression [currently] has an 'ambiguous' value. As has already been pointed out in this thread, an Ada compiler can not determine - simply from its specification - whether a function will have a side-effect or not. (SPARK resolves the issue by extending specifications with annotations; but then it is striking a different balance between flexibility in the design and verifiability of behaviour). I agree with you that it is unwise to write expressions that [unintentionally] have more than one possible value; but I think the point I made still stands. Ada seems to have (as a matter of pragmatism) chosen not to prohibit certain aspects of ambiguity because the potential benefits [in a wide range of cases] out-weigh the pitfalls. [Again, re-affirming my lack of expertise in these matters of the Ada language, the 'pragmatic view' seems to be that: a) people would mostly write functions without side-effects, b) if they are writing functions with side-effects they would/should be especially careful how they use them anyhow, and c) Good performance in embedded real-time systems (on a variety of targets) is desirable [essential if you consider Ada to be targeted at the real-time embedded application market]: consequently, in general the order of evaluation is not fixed; allowing compilers to find an optimal implementation order - including concurrent computation. This may seem even more reasonable if one acknowledges there are other cases where ambiguous behaviour can arise - for instance data aliasing through parameter passing (another thing prevented by SPARK) - so the die is cast!] If your proposal to define the execution order were to be adopted, how might a programmer write the Ada code to express their intent that they don't care what order the expression is executed in (provided it respected the precedence rules) - they just want the most efficient implementation? How much do you think this [manual optimization] would add to/detract from the clarity of the code? How do you think someone who is writing applications for a target that offers high levels of parallel computation would feel about it? -- Stuart Palin