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 11:46:42 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!petbe.visi.com!ash.uu.net!spool.news.uu.net!not-for-mail Date: Thu, 29 Jan 2004 14:46:22 -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: <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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1075405582.982776@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: 1075405583 14599 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:5062 Date: 2004-01-29T14:46:22-05:00 List-Id: 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);