>>>I'm surprised, too - every language I've studied (I haven't studied BASIC :-)) uses 0 for FALSE, and a non-zero positive integer (usually 1, as you noted) for TRUE.
>>
>>Al,
>>
>>I'm not sure why you're surprised. C++ does use a non-zero value positive integer, 1. VB, OTOH, uses -1. The latter I can understand because regardless of the number of bytes, the bitwise compliment (NOT 0, or in VFP BITNOT(0)) of 0 (False) will be -1. Defining True recursively as NOT False makes more sense to me than defining it independently.
>
>I'm surprised because I hadn't heard of ANY language that used -1 for TRUE.
>
>I don't see why TRUE *must* be defined as the bitwise complement of the value of FALSE. As I see it, TRUE is just a placeholder that needs to be defined so that boolean operations proceed as expected; it just has to be different from FALSE. If it makes sense from a storage efficiency standpoint to define it as +1, then why not do so?

If FALSE is defined as zero, NOT FALSE or TRUE should be its exact opposite. Using one bit, the exact opposite (bitwise compliment) of 0 would be 1. Extendeding it to a byte:

0000 0000 - FALSE
1111 1111 - TRUE (or -1)

However,

0000 0000 - FALSE
0000 0001 - TRUE

In the above, TRUE is certainly not equal to FALSE, but neither is it the exact opposite, since 7 of the bits have the same value.

>Defining TRUE as a constant is more efficient than recursively defining it as NOT FALSE. Looking at the command:
>
>X = TRUE

>If TRUE is defined as 1 (or -1, or anything else non-zero) then all that has to happen at runtime is the value is stored.
>
>If TRUE is NOT FALSE, then the value of FALSE must be NOTted (bitwise complement, whatever) at runtime, then the result stored.

When constants are declared, evaluation occurs at compile time not run time. VFP's runtime evaluation, is an exception, at least compared to the way older compilers used to work.