NCOHEN@IBM.COM ("Norman H. Cohen") (05/24/90)
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.)pattis@cs.washington.edu (Richard Pattis) (05/25/90)
I apologize to Norman for quoting out of context; I was confused enough at the time to not understand the necessary context. Part of my confusion was caused by a similar example he gave on page 223, saying Y = 0 OR X/Y = 10 will evaluate both operands (of course, this is before the chapter on exceptions, so it was a true statement based on what was known up to that time). I was certainly hung up on what the compiler must/may do. So, if I have this right, the simplest "correct" thing to say is that AND and OR evaluate their operands fully. The one exception (excuse me) is when the only effect of evaluating the "second" operand is to raise a predefined exception. So, a compiler may optimize an AND to an AND THEN if one of its operands is simple enough for the compiler to verify that the only effect of evaluating that operand is computing a value or raising a predefined exception (no side effects, no possibility of user defined exceptions). "Second" here does not mean "right", since any operand may be evaluated first. Does that cover it; or are there fleas on fleas? Rich Pattis