I think we are talking different things here. You're talking about the order of operands evaluation while I'm talking about the operands priority, so, I see your point.

I wanted to say that "a or b and c" is in fact "a or (b and c)". That doesn't mean the operation between parentheses is evaluated first.

It's like in:

a + b * c

only that, for arithmetic operations, there's no possibility to know the result before complete evaluation.

Anyway, once again, I'm happy that I always use complete parenterized expressions. :)

Vlad

>Neither of those fails my test, as in example 1 a is true so the OR is not checked, in the second a is true so the or is checked and the or has an and in it that needs to be checked for the second part of the expression.
>
>I still see no precedence here, if AND was higher than or then I would expect your example 1 to check all conditions since it should check and before or, it doesn't.
>
>For example;
>
>PROC Testit
>PARAMETERS llTF
>lnCnt = lnCnt + 1
>? lnCnt
>RETURN llTF
>
>Command window
>
>lnCnt = 0
>? Testit(.t.) or testit(.f.) and testit(.f.)
>
>reports that one test was done, the and was never looked at therefore the and is NOT a higher precedence. If it was then the and would have been evalauted before the or was.
>
>Your second example shows also only one test being done. Using .f. for the first expression cuases three tests to be done if the second is .t. and two tests if the second is .f.. Thus the and is only evaluated when the OR is true for the second part (the first part of the or being false).