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 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 01:45:53 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Fri, 30 Jan 2004 10:53:46 +0100 Message-ID: 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> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1075455952 28440664 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5088 Date: 2004-01-30T10:53:46+01:00 List-Id: On Thu, 29 Jan 2004 14:46:22 -0500, 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. Wrong. Here is ARM 4.5: "...For a sequence of predefined operators of the same precedence level (and in the absence of parentheses imposing a specific association), an implementation may impose any association of the operators with operands so long as the result produced is an allowed result for the left-to-right association, but ignoring the potential for failure of language-defined checks in either the left-to-right or chosen order of association." allowed result /= unspecified result The results are specified, they are all possibile ones produced by all possible combinations exectution sequences. There is nothing wrong with that, after all some people are still writing multitasking programs... >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. Writting programs depending on evaluation order in a way that the "correct" order is not specified, that is not a language problem. Programmers should know what they are doing. Do you really believe that tests will detect an "incorrect" order when specified by RM more probably than when selected by the compiler? In my experience errors like this are extremely difficult to detect, no matter whether an order is specified by RM or not. This is why, [and for numerous other reasons] I would like to see pure functions in Ada + procedures with return giving all sorts of warnings when order is not *explicitly* specified. >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. True, this argument would be invalid. But the argument, derived from Gries position, is that the order shall be specified explicitly if relevant to the program semantics. In all cases where the program semantics does not depend on the order, it shall never be specified. Both under- and overspecification are wrong. >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; I presume here the order is also arbitrary. > Point p := (x => cx, y => cy, z=> cz); Anyway there are many orders contradicting each other: type Point is record Z : Coordinate; Y : Coordinate; X : Coordinate; end record; [ + optionally, a nasty represenation clause stating some other, third order ] Is this order[s] irrelevant? Provided that programs are written by idiots, I assure you that 50% of them would believe that keyed associations will not override the native order of record fields. 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? -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de