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-01-29 19:02:39 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2so!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: Thu, 29 Jan 2004 21:02:32 -0600 Date: Thu, 29 Jan 2004 22:02:30 -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: <1075159458.149886@master.nyc.kbcfp.com> <1075225041.167448@master.nyc.kbcfp.com> <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> In-Reply-To: <1075405582.982776@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-5py8qqqVYoNOK0aJCwzn26VygA5si6Q/XolDZOz9xCX0sWPwUiaxc4HAK0O534jkFJGGL8kR/rvkzUq!d51Tw1hE/xX7E2M49KYmoNWxXVtVDzIarHXVNiPzR/cObyeUzbaFRjhCMdi2mg== 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:5083 Date: 2004-01-29T22:02:30-05:00 List-Id: Hyman Rosen wrote: > David Starner wrote: > >> Why should buggy code work? > > I don't think you understand. As Ada stands now, it is perfectly > legal to write code which has unspecified results due to order of > execution. In general, the compiler cannot know whether particular > code has such order dependencies or not, and so cannot reliably > warn of such uses. Therefore, it's possible for such code to slip > undetected into production, and to survive testing because the > order chosen by the compiler is the "correct" one. Then some change > occurs in the environment, such as changing optimization level, > or changing platform, and now the compiler makes a different choice > and the code stops working. > > You cannot make the argument that raesonable care would prevent this. > That is the same argument that C programmers make for the compiler not > checking array bounds or pointer access, and Ada proponents roundly > reject such arguments. > > Therefore, the best thing to do is to eliminate the lack of specificity, > so that a line of code will be executed in the same order always. Once > this is in place, then depending on the order of evaluation within an > expression will be no more problematic than depending on the order of > execution of a pair of statements, and will not be "buggy". As for its > utility, I submit that code like this: > Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord); > is perfectly sensible once you forget that order of evaluation was ever > an issue and accept left-to-right as the natural way of things. Why is > this statement any worse than > cx, cy, cz : Coord := ReadCoord; > Point p := (x => cx, y => cy, z=> cz); What determines whether something is a bug? On many projects it is in the mind of the programmer, and nowhere else. I prefer to work on projects with defined and written testable requirements, and to allow these to define what is a bug. If the SDP says to use SPARK, then any dependence on evaluation order is a bug, and it will be caught by the SPARK toolset. If the SDP says something else, that will either establish guidelines that define functions with side-effects to be bugs, or which make calling two functions with mutual side-effects a bug. Any of the the later approaches are fine with me, and are consistent with programming in Ada. But you have to expect that I will regard any language revisions which attempt to change those bug definitions as a non-starter. Notice that you are welcome to use SPARK if you want, and in fact I have worked with it on occasion. But on other projects I have worked on, other definitions of bugs have been used. To change the rules now would make lots of code obsolete. Going through and reevaluating the programs according to the new rules is possible. But without an automated toolset it is very expensive. If there are significant upward incompatibilities in Ada 0Y, expect most compiler vendors to plan to provide such migration tools. Now think about the effort required to develop the tools for your proposed change, and go away. Note that SPARK is a subset of Ada, and such a toolset does exist for SPARK, so I am not saying it is impossible. Just that you are in effect defining a new language, and the market for that language is currently served by SPARK and the SPARK toolset. -- 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