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-30 12:28:33 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!nntp.abs.net!ash.uu.net!spool.news.uu.net!not-for-mail Date: Fri, 30 Jan 2004 15:28:33 -0500 From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions References: <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> <1075482385.142744@master.nyc.kbcfp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1075494512.11913@master.nyc.kbcfp.com> Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) NNTP-Posting-Host: 204.253.250.10 X-Trace: 1075494512 10652 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:5122 Date: 2004-01-30T15:28:33-05:00 List-Id: David Starner wrote: > They don't sneer about unmaintainable code that they > could make deterministic at the cost of good code. The example I have previously posted, p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord); is not "unmaintainable", except that it is non-deterministic in current Ada. On the other hand, the following code cx, cy, cz : Coord := ReadCoord; p : Point := (x => cx, y => cy, z => cz); is perfectly deterministic. Is it unmaintainable? Perhaps. But the point is that someone might innocently code the first case, most likely in a less obvious way, and it might survive all checking and testing, because such things do, just like buffer overflows stay in C/C++ code. The "cost" to good code is a phantom, trotted out as an excuse for maintaining the status quo. > What happens when someone uses f-f later assuming it will be 1? With a defined order of execution, if it wasn't 1 before it wouldn't be 1 now, and the tests would fail, demonstrating the error to the programmer. With an arbitrary order of execution, it will turn out to be 1 in the debug build and -1 in the production build, returning the wrong answer at the worst possible time. > Or if someone changes the code not to call f-f and fails to make > the side effects that something else is depending on? Then the code will fail, and testing will show that it has failed. > This is bad code, and needs to be fixed at the program level, > not the language level. Whether or not the code is bad, I believe that it can readily slip through checks into production because it works by coincidence. It cannot be fixed at the program level any more than array overflows can be fixed at the program level.