>>>>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.

I understand your point, that, mathematically, -1 is an "elegant" "opposite" of 0, when using 8 bits to represent the value. However, using only 1 bit, clearly 1 is the "opposite" of 0. Perhaps more importantly, to reiterate, I know of no RFC or other convention in this business that recommends that the definition of "opposite" should be "bitwise complement".

>
>>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.

Sure - that's an easy optimization for a compiler to make. OTOH, I don't think the language specification is supposed to define how a preprocessor or compiler does its job, or to rely on such features it might or might not have.