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 09:06:26 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!spool.news.uu.net!not-for-mail Date: Fri, 30 Jan 2004 12:06:26 -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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1075482385.142744@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: 1075482385 10652 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:5103 Date: 2004-01-30T12:06:26-05:00 List-Id: Dmitry A. Kazakov wrote: >>it is perfectly legal to write code which has unspecified results >>due to order of execution. > > Wrong. Here is ARM 4.5: > allowed result /= unspecified result That very same section says that The two operands of an expression of the form X op Y, where op is a binary operator, are evaluated in an arbitrary order, as for any function_call arbitrary order = unspecified result If I have (pidgin Ada again!) x : 0..1 := 0; function f : integer is begin x := 1 - x; return x; end f; r : integer := f - f; Then Ada legally permits r to be 1 or -1. That's what I call unspecified, i.e., no single result is required. In a particular fixed environment, it is likely that the above code will always return the same value. If this is done in production code rather than in a contrived example, and the order dependency isn't so apparent, it will seem that everything is fine. Then a change in environment can make the opposite result appear, and things may be broken. Everyone here is saying "so don't do that", which is what we C/C++ programmers always say, and which you Ada guys sneer at. > Do you really believe that tests will detect an "incorrect" order > when specified by RM more probably than when selected by the compiler? I believe that once code is written, tested, and found to work, then having the evaluation order chosen by the language means that it will continue to work even when the environment changes. If the order is selected by the compiler, then you have no such assurance. Surely this is obvious? > In my experience errors like this are extremely difficult to detect With a defined rather than arbitrary order, this might no longer be an error. Removing sources of uncertainty in the language is good. > Both under- and overspecification are wrong. Nevertheless, in conventional programming languages overspecification is the rule, and it is what programmers are used to. It is left to the compiler to rearrange things if it can prove that the result remains correct by the rules of the language, just as in the section you quoted. >> cx, cy, cz : Coord := ReadCoord; > I presume here the order is also arbitrary. No, it is not. See 3.3.1/7. The order is strictly left-to-right. > 50% of them would believe that keyed associations will not override the > native order of record fields. I don't believe that for a second. Making up dumb statistics in order to bolster an untenable position is silly. > Or do you think that the guessing the results of: > Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord); > Point P1 := (ReadCoord, ReadCoord, ReadCoord); > Point P1 := (Y => ReadCoord, others => ReadCoord); > should be blessed as a symphony of safety and maintainability? Yes, actually I very much think so, and there should be no guessing involved.