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-02-25 07:53:36 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!news.octanews.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Wed, 25 Feb 2004 10:53:12 -0500
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
References: <1075987360.225622@master.nyc.kbcfp.com> <40236C0B.E988E003@0.0>
 <xay_b.429$ax2.177@nwrdny03.gnilink.net>
 <pan.2004.02.24.01.44.30.311621@email.ro>
 <1077634311.254581@master.nyc.kbcfp.com>
 <pan.2004.02.24.23.23.33.578111@email.ro>
 <mailman.20.1077669870.327.comp.lang.ada@ada-france.org>
 <pan.2004.02.25.09.01.17.858502@email.ro>
 <1077718871.47635@master.nyc.kbcfp.com>
 <54cp3095jmv8s17h63d4bjdus0tec7l7pt@jellix.jlfencey.com>
 <1077721343.481619@master.nyc.kbcfp.com>
 <ljgp301lgj3r0totpo3hlkmt3dbnbe0i33@jellix.jlfencey.com>
In-Reply-To: <ljgp301lgj3r0totpo3hlkmt3dbnbe0i33@jellix.jlfencey.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1077724400.221032@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: 1077724400  6522 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:5794
Date: 2004-02-25T10:53:12-05:00
List-Id: <comp.lang.ada>

Vinzent 'Gadget' Hoefler wrote:
> Think of the case where "+" might not be commutative.

Exactly. So as I said, Ada has no philosophy that a + b
means the same thing as b + a. Thus it is not a relevant
argument against specifying order of evaluation.

> There's no equivalent of an Ada's "and" and "or" where the compiler
> can evaluate if the comparison with the result of a costly square-root
> function should be delayed until we can figure out if the simple
> boolean flag already gives us the result:
> 
> |if (Sqrt (x) > 5.0) and b then ...

How would knowing that b is false help the compiler not call the
costly operation? The rules of Ada require that for "and", both
operands are evaluated! If you are really intent on writing such
code in C or C++, you may say !!a & !!b, where the hideousness
will give a clue to the reader that something weird is going on.

> BTW, the above is another reason why you shouldn't write functions
> with side effects, because if you do the compiler *has* to evaluate
> Sqrt, too. :-)

If the compiler knows enough about Sqrt to know that it has no side
effects, then it will have no problem checking b first even if you
write (sqrt(x) > 5.0 and then b).

Really, all these arguments sound so desperate.