Short Circuit Evaluation

Hey, Ted:

Here's a simplification of the code for subprocedure EqAnyNum, which you published on January 28. I was able to shorten the code because of a feature called short circuit evaluation, which is explained in chapter 21 of the V5R2 RPG IV reference.

--Mel

Thanks to Mel for bringing short circuit evaluation to my attention. Here's Mel's code.

C/free                                    
     if %parms >= 2 and BaseVal = Val01 or
        %parms >= 3 and BaseVal = Val02 or
        %parms >= 4 and BaseVal = Val03 or
        %parms >= 5 and BaseVal = Val04 or
        %parms >= 6 and BaseVal = Val05 or
        %parms >= 7 and BaseVal = Val06 or
        %parms >= 8 and BaseVal = Val07 or
        %parms = 9 and BaseVal = Val08;   
            return *on;                   
        else;                             
            return *off;                  
        endif;                            
 /end-free                                

If you compare it with my code, you'll see that Mel's code is shorter. But both versions of the EqAnyNum routine work correctly, so neither one is better than the other from a standpoint of correctness.

Mel's code interests me because it points out a particular behavior of the compiler. It shows that the compiler stops evaluating a complex condition as soon as it can determine whether the condition proves true or false.

If two conditions are connected by an AND, both conditions must be true in order for the complete condition to be true. If the first condition is false, there is no need for the compiler to resolve the second condition. The situation is similar for OR'd conditions. If the first condition is true, there is no need to test the second condition.

Whether or not a language processor short-circuits compound conditions may make a difference. The RPG reference manual provides a brief explanation of this. If the second condition is a call to a function subprocedure that modifies something, then whether or not the second condition gets tested makes a difference.

There is no universal law regarding how language processors (compilers and interpreters) resolve compound conditions. Some compilers short-circuit the test, while others resolve all conditions before returning a verdict for the complete condition. Java permits both types of tests. The & & and || operators implement short-circuited conditions, while the & and | operators evaluate both parts of a compound condition.

Having learned that the RPG IV compiler short-circuits compound conditions, I decided to see if all iSeries language processors did the same.

First I tested the RPG III language. I wrote two short RPG programs using the ANDxx and ORxx op codes. Here's the OR version.

C           *ENTRY    PLIST                    
C                     PARM           P1      10
C                     PARM           P2      10
C*                                             
C           P1        IFEQ 1                   
C           P2        OREQ 2                   
C                     MOVE *ON       *IN01     
C                     ELSE                     
C                     MOVE *OFF      *IN01     
C                     ENDIF                    

I discovered that the compiler does not test the second condition if the first condition proves true for OR, or false for AND.

Next I tested AND and OR logic in an OPM CL program.

PGM   (&P1 &P2)

DCL &P1 *DEC 1                 
DCL &P2 *DEC 2                 
DCL &TEST *CHAR 1              
                               
IF (&P1 *EQ 1 *OR &P2 *EQ 2) DO
   CHGVAR &TEST 'T'            
ENDDO                          
ELSE DO                        
   CHGVAR &TEST 'F'            
ENDDO                          

I called this program from a command line, passing parameter values of X'1F' and X. The program cancelled with a data decimal error, showing that CL tests both conditions in all cases.

Having found a compiler that does not implement short-circuited evaluation of compound conditions, I short-circuited my test. If you're curious about COBOL, REXX, Qshell, etc., you'll have to do your own tests.

--Ted