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-27 09:37:22 PST
Path: 
 archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshosting.com!nx02.iad01.newshosting.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!uunet.MISMATCH!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Tue, 27 Jan 2004 12:37:21 -0500
From: Hyman Rosen <hyrosen@mail.com>
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: <wcczncdrowb.fsf@shell01.TheWorld.com>
	<mailman.15.1075065014.2270.comp.lang.ada@ada-france.org>
	<wcc8yju2tjk.fsf@shell01.TheWorld.com>
	<1075159458.149886@master.nyc.kbcfp.com>
	<wcc4qui2sec.fsf@shell01.TheWorld.com>
	<d%jRb.1212$nR.528@nwrdny01.gnilink.net>
 <mailman.35.1075191506.2270.comp.lang.ada@ada-france.org>
In-Reply-To: <mailman.35.1075191506.2270.comp.lang.ada@ada-france.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1075225041.167448@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: 1075225041  7113 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:4913
Date: 2004-01-27T12:37:21-05:00
List-Id: <comp.lang.ada>

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. 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. And Ada compilers already know how to do things
in defined order since they must compile 'and-then' and 'or-else'.

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++.