AND and expression evaluation

[NCOHEN@IBM.COM ("Norman H. Cohen")]

Ref: INFO-ADA Digest Volume 90 Issue 104 (Wed, May 23, 1990) Item #2
     INFO-ADA Digest Volume 90 Issue 104 (Wed, May 23, 1990) Item #3

Rich Pattis (pattis@june.cs.washington.edu) quoted Ada as a Second
Language out of context.  A more complete excerpt is:

> ... In the evaluation of an arithmetic expression, an intermediate
> result that overflows may raise Numeric_Error, but it is not
> guaranteed to do so.  There are several reasons for this:
>
>   An implementation may choose not to raise Numeric_Error in an
>      expression whose ultimate result can be determined without
>      actually performing the overflowing operation.  For example,
>      an implementation may choose to optimize the expression
>
>           b /= 0 AND a/b > c
>
>      by evaluating it as if it were written
>
>           b /= 0 AND THEN a/b > c
>
>      Then a value of zero for b would not raise Numeric_Error.
>      However, this optimization is up to the individual compiler.
>      A programmer is guaranteed of avoiding the exception only by
>      writing the short circuit control form.
>
>   ...

Thus John Barnes and I agree that the "normal" semantics of AND is
to evaluate both operands, and that the only way to GUARANTEE that
the right operand won't be evaluated when b=0 is to write AND THEN.

The optimization of not evaluating the right operand of AND, even
though the division operator might raise an exception, is allowed by
reference manual paragraph 11.6(7), which states, "A predefined
operation need not be invoked at all, if its only possible effect is
to propagate a predefined exception."  If the right operand had been

   My_Function (a,b) > c

rather than

   a/b > c

such an optimization would not be allowed.

(By the way, AI-00387 now allows and encourages an implementation to
raise Constraint_Error rather than Numeric_Error in contexts where the
reference manual calls for Numeric_Error to be raised.)