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-06 02:27:25 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!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: Fri, 06 Feb 2004 10:27:23 +0000 Organization: Computer Sciences Corporation Message-ID: <40236C0B.E988E003@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> <402232E9.3EE15B4B@0.0> <1075987360.225622@master.nyc.kbcfp.com> NNTP-Posting-Host: 20.44.240.16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: lore.csc.com 1076063243 2223 20.44.240.16 (6 Feb 2004 10:27:23 GMT) X-Complaints-To: abuse@news.csc.com NNTP-Posting-Date: Fri, 6 Feb 2004 10:27:23 +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: 6 Feb 2004 10:22:58 GMT, rc2966.rochstr.gmav.gecm.com Xref: archiver1.google.com comp.lang.ada:5276 Date: 2004-02-06T10:27:23+00:00 List-Id: Hyman Rosen wrote: > > 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. > > Those benefits being? > > > allowing compilers to find an optimal implementation order ... allowing compilers to find an optimal implementation order!??? > But you are now talking about finding an optimal implementation > order for an expression involving more than one function call > where the compiler has no access to the body of the functions. > Do you really think that allowing the compiler to pick the order > of the calls will significantly affect the efficiency? > > > - including concurrent computation. Yes - as Robert Eachus has illustrated much better than I could. > Eliminating sources of ambiguity is a good thing even if not all > of them can be removed. Agreed, but to emphasize the point made by Robert Eachus - if the rules you introduce are too complex the cure is worse than the disease. There is some merit in having a set of rules that are perhaps imperfect, but are simpler to understand: at least you are sure of where you stand. > > 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 > > They could not, just as they cannot specify this for sequences > of statements. If you write > x := a + b; > y := c + d; > you may not care which statement is executed first, but you have no > way of telling this to the compiler. Either the compiler can figure > this out for itself, or it can't. or you could possibly identify that x and y are part of a common object and so might be processed jointly: type doublet is record x : ... ; y : ... ; end record; ... XY : doublet; ... XY := doublet'(x => a+b, y => c+d); If they are truly unconnected objects then perhaps they should be processed in separate tasks. However, I think that in practice the language has taken a pragmatic view of where to draw the line in balancing 'ambiguity' of order with optimization: within a single expression the order of evaluation may be ambiguous, between separate statements it may not. -- Stuart Palin