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-27 12:07:38 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: 27 Jan 2004 15:06:57 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1075159458.149886@master.nyc.kbcfp.com> <1075225041.167448@master.nyc.kbcfp.com> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1075234017 23253 192.74.137.185 (27 Jan 2004 20:06:57 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 27 Jan 2004 20:06:57 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4926 Date: 2004-01-27T15:06:57-05:00 List-Id: Hyman Rosen writes: > Stephen Leake wrote: > > Hmm. It's very unlikely that Ada will change to define the order of > > execution in expressions. There are good reasons to leave it undefined > > (different optimizations for different targets or speed/space goals, > > for example), and changing it would be work for existing compilers. > > Those are not good reasons, those are "We've Always Done It This Way" > reasons. It would be some work for compiler vendors, but it would be > only a benefit for Ada programmers. Probably true. >...For the typical case where order > doesn't matter, adopting the new rule doesn't hurt optimization since > the compiler is always free to use its as-if license to do things in > any order it wants to. No, that is not correct. Compilers cannot tell, at compile time, whether the order matters (in many cases). Therefore, they cannot optimize many of the cases where order does not matter, if the rule were changed to "left-to-right". On the other hand, I suspect that order-changing optimizations are not really all that important for speed. >... And Ada compilers already know how to do things > in defined order since they must compile 'and-then' and 'or-else'. Yes, and they also know that statements in a sequence must be executed in order. But that certainly does *not* mean that it would be easy to change existing compilers to obey left-to-right order for subprogram parameters. There is *no way* that Ada will change to require left-to-right. It's simply too hard for existing compilers, even if you can convince us compiler writers that the potential optimizations don't matter much. And there is *no way* the rules will change to require side effects to be evident to the compiler (and user!) at the call site. Too much incompatibility. So we're stuck, like C and C++, with an order that's up to the whim of the compiler writer. > You are arguing that for the convenience of compiler vendors, programmers > should be subjected to a gratuitous source of non-portability, which they > must avoid by being careful when they code, rather than having the language > protect them. Oddly enough, this is the attitude that Ada proponents are > always denigrating about C++. Right. - Bob