>>>Jim,
>>>
>>>> This "proves" that the so-called VFP 'optimization' is a figment of the imagination
>>>
>>>This is a completely false statement. If you use function calls in place of memvars in the logical expression, you will in fact be able to trace the execution and see that VFP will do it's own optimization. I'd point you back at the code I posted earlier in the thread as a starting point. The expression in that code was purposely constructed to be non-optimizeable to show that VFP correctly understood the operatir precedence. If you run ? t1() or t2() and trace it the t2() function WILL NOT BE CALLED, the optimizer knows that calling it can not change the end result, so it doesn't call it.
>>
>>David,
>>
>>Agreed with your statement. However what Jim said about VFP having to evaluate the operator type ( i.e. AND, OR, etc. ) is required to determine whether the expression result must be evaluated, correct?
>>
>>Bill
>My 2 cents.
>I prefer to use the word 'recognize' as Jim Nelson did a few messages back. VFP recognizes the OR expression and optimizes accordingly. The actual evaluation occurs according to the precedence schedule.
>I thought the best conclusion showed up yesterday in which the statement that
>
>a or b and c is evaluated by default as a or (b and c) rather than (a or b) and c. That eliminates discussion of compiler optimization which would occur under either interpretation.

Agreed. But any way you state it, if "a" is evaluated to .T., the operator after it must be evaluated ( OR or AND ) to determine if further evaluation of the expression is required.