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-28 10:18:21 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!news.he.net!cyclone-sf.pbi.net!216.196.106.144!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: Sat, 28 Feb 2004 12:18:20 -0600 Date: Sat, 28 Feb 2004 13:18:19 -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> <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> <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <82347202.0402251405.2db2f3c5@posting.google.com> <1077747598.55635@master.nyc.kbcfp.com> In-Reply-To: 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-OEJN3WDXxkV0FwyEWkplXx5kOMycRTQwVYBwdhKPwyvqSigNE1C1d0lwWIJcAz0hO/E0exl7T1uthcJ!GHUMGNKcAM8qR6CPpUJBwD+j48p0eZXuTiS8KN1qUI/bXRPYpiIHmn7GqspyIA== 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:5931 Date: 2004-02-28T13:18:19-05:00 List-Id: I said: >>If a user wants to, he can use other language rules (and code that >>makes it obvious that it is intentional) to force a particular >>evaluation order. But it is much harder to do that than to make the >>code agnostic about evaluation order, and that is intentional. Stephen Leake wrote: > Ok. Some of us don't understand why it is harder; that would be a > useful thing to talk about. I am probably not the best one to ask about it, since believe it or not, one of my personal fights during the Ada 9X development process was that it should be POSSIBLE to force an evaluation order. But I'll give it a try. In modern CPUs synchronization calls that allow "precise" interrupts are very expensive, in an execution time sense of course. In Ada, this means that requiring variables to have specific values when Constraint_Error is raised. Or for that matter when any predefined exception is raised. But in practice the interesting cases are for Constraint_Error. If there is a specified order, then someone can write a test that raises Constraint_Error in "interesting" places, and looks at the values of variables in the handler. In Ada 83, there was a huge, nasty AI, AI-315, that looked at this issue and RM 11.6 in general. (Notice that section 11.6 Exceptions and Optimization in the Ada 83 manual corresponds to 11.6 in Ada 95. This was very intentional.) The debate over what to do about this "problem" in Ada 83 was never resolved. In theory, the freedoms granted in (Ada 83) 11.6 could be used to make almost any program do anything. But in practice there were some very strict rules that made it almost impossible for compilers to "take advantage" of these freedoms. The tension was that the compiler vendors wanted to get rid of some of the more onerous requirements. But those who wrote programs which needed to raise (and handle) Constraint_Error were of course concerned that Constraint_Error not turn into something where any attempt to handle Constraint_Error could cause the hard drive to be overwritten. The current solution as far as I am concerned goes a little too far in the direction of allowing optimizations at the expense of making exception handlers more difficult to write. In fact, you sometimes have to insert a call to an independent subprogram just to guarantee the necessary semantics. "An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and has no Inline pragma applied to it. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be disrupted by the raising of the exception, causing the object or its parts to become abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1." (RM 11.6(6) where else?) As far as programs that don't have to deal with Constraint_Error handlers are concerned though, the situation is much better. If you split a complex expression into a series of assignment statements, the order of evaluation is not guaranteed, but you do get "as if" semantics. (Again, absent Constraint_Error being raised.) -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke