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,54889de51045a215 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-12 17:42:59 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3F89F4E9.7050601@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: += in ada References: <3F7316F7.219F@mail.ru> <49cbf610.0310070205.2937e71a@posting.google.com> <3F896BAB.6040804@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc04 1066005778 24.34.139.183 (Mon, 13 Oct 2003 00:42:58 GMT) NNTP-Posting-Date: Mon, 13 Oct 2003 00:42:58 GMT Organization: Comcast Online Date: Mon, 13 Oct 2003 00:42:58 GMT Xref: archiver1.google.com comp.lang.ada:757 Date: 2003-10-13T00:42:58+00:00 List-Id: > So, Robert and/or "Bob", would it be acceptable to the Guardians Of Ada's > Purity if the semantics of a new "idem" feature were to specify that: > x := f(idem); > could leave an arbitrary value in x in the event of a Constraint_Error being > raised; thus always permitting an update-in-place implementation? Robert would say no, Bob would say yes. The ARG would spend a couple of hours discussing it and not change the current situation. ;-) In other words, right now IF you need to you can write things so that x won't get corrupted. Also you will normally get the fastest possible code generated. It is only when those two principles collide that there is an issue. Robert was happier with the Ada 83 rules. Bob prefers the Ada 95 rules. But in 90+ percent of the cases where Constraint_Error can occur, there are no practical differences between the rules. If you are really concerned with insuring that the value of x doesn't get assigned a value even temporarily out of range, the new rules are more difficult to understand and follow. Of course Bob would say that if you want good code, the Ada 95 rules are easier to work with. The funny thing about all this is that in the debates about 11.6 over the years, people named Robert or Bob have been very active and vocal in expressing all possible points of view, mostly Bob Duff, Robert Dewar, and myself. Bob Duff and I come the closest to being the Robert and Bob of the dialog, and Robert Dewar can certainly pinch hit for either one of us. But that gets back to something that is hard to explain to people who haven't sat in on an ARG meeting. It is a very strenous intellectual exercise, but we are all concerned with insuring that all possible issues are examined before the ARG makes a decision. If you look at the history of some issues, we would meet vote 10-0 for some position and delegate someone to write the decision up. The draft AI would then get voted down say 8-3, a new position agreed to, and the process repeated. I'd have to check what the record on a single AI was, but Ada 83 AI-315 was about this issue and was never completely resolved. A lot of the new language in Ada 95 is supposed to resolve it, and I have yet to see a serious complaint from outside the ARG. But it is an extremely difficult issue. Let me give you the canonical problem, and see if you want to take a shot at it: with Text_IO; use Text_IO; with Integer_Text_IO; use Integer_Text_IO; procedure Issue is X,Y,Z: Integer := 0; begin Get(X); Get(Y); if X * Y > Integer'Last then Put_Line("Overflow!"); else Z := X * Y; Put_Line("Okay"); end if; exception when Constraint_Error => Put("Exception Raised. Z = "); Put(Z); New_Line; end Issue; What is the correct behavior for this program, if (mathematically) X times Y is greater than Integer'Last? In Ada 83, in theory you could have a compiler that legally printed Okay, Overflow, or Exception Raised. In Ada 95 we think we have ruled out Okay, but doing so is tough. Of course the argument we are having here is about the value of Z in the exception handler. That is a much easier issue than whether you get Overflow or Exception Raised. (If it matters to you, consider it implementation dependent, and test the exact code you care about.) -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig