Re: and then... (a curiosity)

[Brian Drummond <brian_drummond@btconnect.com>]

On Tue, 02 Sep 2008 16:50:34 -0400, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>>> When I was at Polytechnic first language was PL/1, second Pascal and
>>> therefore methodology was different. i.E. Don't rely on the execution
>>> order of boolean expressing.
>>
>> This I also agree with, although I admit being used to the short circuit &&
>> forms in the C-like languages.
>>
>> But my point is about having the source code be clearer when both
>> operands are required to be evaluated, especially when this is a
>> possibility:
>
>It seems to me that two cases come up in practise, for "A and [then] B".
>Either I don't care which gets evaluated first, and don't care whether
>or not both get evaluated, because there are no important side effects
>(that's "A and B"), or I care about order (that's "A and then B").
>
>I never see cases where it is important that A and B both be evaluated.
>
>Counterexamples, please?  ;-)  Realistic ones, I mean.

Given the speed penalty for branches, there are circumstances where it
is faster to evaluate both cases than branch around one. In that sense,
it would be important (for performance, rather than semantics) to
evaluate both cases. But that is properly the compiler's decision to
make.

I don't think that's what you meant; I believe you meant "important for
semantics"

But it does illustrate that (I) "and then" (short circuit form, order
guaranteed) and (II) "and" (short circuit permitted, but not guaranteed,
order not guaranteed) are properly separate operations.

For cases such as the logging example (semantics require both to be
evaluated) my personal choice would be to explicitly evaluate both, and
combine their evaluation results, as elsewhere in this thread. 

Is my understanding of Ada correct in expecting this is the only way to
guarantee evaluation of both? ( i.e. Ada handles "and" as (II) above)

- Brian