Vlad,

>>Pardon my nose here Vlad, but does " But if "a" is .F., the "and" is evaluated, and this is done before "or". " make sense... after all, for "a" to be known to be false, it has to have already been evaluated.
>
>So, my statement doesn't make sense (?). Probably it makes sense only in MY English. :) As I said in a previous message, the precedence of operators gives the way to group operands, not the sequence (in time) to evaluate operands. My statement wanted to say:
>1. The "and" operation is evaluated only if "a" is .f.

Yes, that is true for the EXPRESSION which has the AND in it, BUT the AND itself got 'attached' to its operands *BEFORE* any expression evaluation was done. Before *any* expression part was evaluated, in fact.

>2. If "a" is .f., the result of the "and" operation is evaluated before the result of the "or" (which will be the final result).

At least partially correct, and maybe fully correct. I agree that the AND result must be known in full, but I am not sure if the OR is considered before or after that happens.

>
>Does it make sense now?
>
>>And don't forget that we know, because of a prior bug in FP/VFP with syntactical-error/type-mismatch in non-first expressions of compound logical expressions, that evaluation always proceeds left to right.
>
>We know that from the help (See "Creating Logical Expressions"). This is true as long as all operations have the same priority. This rule cannot beat the normal precedence of operators. And the sequence of operation evaluation is not necessarily the same as the order of operands evaluation. The example in this thread proves it.
>
>>The precedence involved here has to do with the operators and which operands will be attached to which - *not* to the actaul expressions themselves.
>
>How come the operator's precedence doesn't have anything to do with the expressions themselves?
>
Because once the operators are 'attached' to their operands, evaluation of the expressions proceeds from left to right.

Jim N


>Vlad