Vlad,

>>2) The evaluation of the expression proceeds from left to right in every case.
>
>While this is true, it can be interpreted by some readers as a statement that logical operators has the same priority.
>
>Just to be clear, for the expression in this thread, the order is the following:
>
>1. "a" is evaluated. If .t., the result is already known and the evaluation stops. If .f., go to 2.
>2. "b" is evaluated. If .f., the result is known and the evaluation stops. If .t. go to 3.
>3. "c" is evaluated.
>4. "b and c" is evaluated.
>5. "a or (result from 4.)" is evaluated.
>
>So, it's clear that the OR is never evaluated before AND. The ilusion is done by the optimizations applied to logical expressions.
>
No, I don't think so!

In your item #1, with "a" evaluating to true, the result cannot ALREADY be known *until* the OR is encountered and 'recognized' as such. If it was followed by a AND (instead of a OR) then the result would *not* already be known. The only way to recognize the difference is to 'evaluate' the operator following the initial expression (in this case) and to make the decision accordingly.

As you also know, and it is true for virtually every language, the programmer is always told to 'optimize' logical expressions by placing the known most "restrictive" condition(s) first so that the result can be determined with the minimum of execution cycles. This "proves" that the so-called VFP 'optimization' is a figment of the imagination - such 'optimization' is the programmer's responsibility and always has been. In fact we are all so used to it that none of us even considered writing the statement as b AND c OR a, did we < g >?! (or, alternately, [(b AND c) OR a ]

Getting back to the issue... evaluation (I prefer to call it 'attachment of operands') of the operators themselves occurs before any EVALUATION of expressions. This is the only way that I can see for this to work properly and as observed in every case.

Cheers,

Jim N

>Vlad