Re: Multiple Conditions on a DOW loop

Kurt,

Different languages have different evaluation orders for processing "and"

and "or" logic in a condition? I always thought the left to right process
of handling a condition was standard across the board. I'm curious what
these are (and really, why is it different).

Different operators can have a higher or lower operator precedence, which
(in the absence of parentheses) can mean things are not evaluated in a
strict left to right fashion, even aside from optimizations which Chuck
points out. In arithmetic, a simple example is 1 + 2 * 3 which should equal
7 and not 9. The V4R5 manual lists the precedence as:

The following list indicates the precedence of operations from highest to

lowest:

1. ()
2. Built-in functions, user-defined functions
3. unary +, unary -, NOT
4. **
5. *, /
6. binary +, binary -
7. =, <>, >, >=, <, <=
8. AND
9. OR

But it also has a section on "Order of Evaluation" which says in part:

"The order of evaluation of operands within an expression is not guaranteed.

Therefore, if a variable is used twice anywhere within an expression, and
there is the possibility of side effects, then the results may not be the
expected ones.

For example, consider the source shown in Figure 169<http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books_web/c0925086558.htm#FIGFSIDFX>,
where A is a variable, and FN is a procedure that modifies A. There are two
occurrences of A in the expression portion of the second EVAL operation. *If
the left-hand side (operand 1) of the addition operation is evaluated first
*, X is assigned the value 17, (5 + FN(5) = 5 + 12 = 17). *If the
right-hand side (operand 2) of the addition operation is evaluated first*,
X is assigned the value 18, (6 + FN(5) = 6 + 12 = 18). "

You must also consider that some languages / compilers do "short circuit
evaluation" and some do not. RPG does, but not all languages do.

The manual says this about short circuit evaluation:

"Relational operations AND and OR are evaluated from left to right.
However, as soon as the value is known, evaluation of the expression stops
and the value is returned. As a result, not all operands of the expression
need to be evaluated.

For operation AND, if the first operand is false, then the second operand
is not evaluated. Likewise, for operation OR, if the first operand is true,
the second operand is not evaluated.

There are two implications of this behaviour. First, an array index can be
both tested and used within the same expression. The expression

I<=%ELEM(ARRAY) AND I>0 AND ARRAY(I)>10

will never result in an array indexing exception.

The second implication is that if the second operand is a call to a
user-defined function, the function will not be called. This is important if
the function changes the value of a parameter or a global variable."

I always hate it when a language does NOT do short circuit evaluation, in
large part because of the array index thing.

When you work in a new language, you ALWAYS want to make sure you review its
rules on operator precedence, short-circuit evaluation, etc.

IMHO