From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 8 Apr 93 15:34:59 GMT
From: tinton.ccur.com!cjh@princeton.edu  (Christopher J. Henrich)
Subject: Re: and then
Message-ID: <1993Apr8.153459.8896@tinton.ccur.com>
List-Id: <comp.lang.ada>

In article <1993Apr7.162133.3564@nosc.mil> sampson@nosc.mil (Charles H. Sampson
) writes:
>     My style is to use the boolean operators generally, reserving the
>short-circuit forms to document that the second operand should not be eval-
>uated under some circumstances.
>
>     Unfortunately, that style can conflict with efficiency considerations. 
>Ada compiler writers appear to have abdicated their responsibility and make
>no attempt to determine when boolean operations can be optimized as short-
>circuit.  (Somebody contradict me, please.)  
All right....

The C3Ada compiler, which runs on the Series 3200 machines produced
by Concurrent Computer Corporation, does optimize AND into AND THEN;
likewise, OR into OR ELSE.  As you point out, this is legal only if
the operands are free of side effects - basically, calls to user
defined functions.  And there are circumstances where the
transformation, though legal, is not optimal, such as

   FLAG1 := FLAG2 and FLAG3;

The compiler tries to avoid doing the transformation in such cases.

>... [T]here are cases when it is unreasonable to expect such an optimization; 
> when the
>second operand contains a function reference, for example.
>
>     That said, I still use my style when coding and look for bottlenecks
>during testing if performance is poor.  If efficiency requires that I use
>an unnecessary short-circuit form, I document that fact in the code.
>
>                                   Charlie
>

Regards,
Chris Henrich