Logical Operators

The four logical operators and, or, xor, and not are used to determine the "truth" of an expression. e.g.

        1 and 1     -- 1 (true)
        1 and 0     -- 0 (false)
        0 and 1     -- 0 (false)
        0 and 0     -- 0 (false)
        1 or 1      -- 1 (true)
        1 or 0      -- 1 (true)
        0 or 1      -- 1 (true)
        0 or 0      -- 0 (false)
        1 xor 1     -- 0 (false)
        1 xor 0     -- 1 (true)
        0 xor 1     -- 1 (true)
        0 xor 0     -- 0 (false)
        not 1       -- 0 (false)
        not 0       -- 1 (true)

Function-style equivalents of these operators can also be applied to entire sequences, as explained shortly in Sequence Operations, eg
sq_and({true,{false,true}},{true,false}) ==> {true,{false,false}}.

In all cases short-circuit evaluation is used for expressions containing and or or.

The constants TRUE, True, true, FALSE, False, and false are automatically builtin to the Phix compiler. There is no difference between the different cases, which makes for one less thing you have to remember.

You may also find these operators applied to numbers other than 1 or 0. The rule is: zero means false and non-zero means true. So for instance, replacing variable names (which might make more sense) with literal values to show exactly what is going on:

        5 and -4    -- 1 (true)
        not 6       -- 0 (false)

One could argue the above is relatively poor practice. The equivalent expressions "5!=0 and -4!=0" and "6==0" yield the same results and (at least when using sensible variable names rather than those meaningless literals, and likewise false rather than 0) can communicate the intent with greater clarity. Should there be any cases where the latter forms generate slightly less efficient code, they should be logged as a bug in the compiler. There are, however, countless instances of this sort of practice in legacy code, far too many to ever fully eradicate, especially given that attempts to do so are likely to introduce new bugs (even if they are schrödinbugs¹), plus there is also the trick (often seen as !! in other programming languages) of using not not to prove something is or cast it to a bool.

One case worth mentioning is the popular idiom [not] find(needle,haystack), for which encouraging the programmer to tack "=0" or "!=0" onto the end does not really improve anything, and smacks of pedantry and pettiness, but of course there is exactly the same 0 means false and anything else means true.

Parenthesis is required to mix different logical operators in a single expression, as explained below the Precedence Chart.

See Also:

and_bits, or_bits, xor_bits, and not_bits, which are the corresponding bitwise functions, or the ARM data processing operations.

Technicalia

1schrödinbug: a bug that occurs after the programmer notices that the code should never have worked in the first place, then typically manifests itself all over the shop, hampering attempts to rectify it, for reasons you can never quite grasp and despite having passed all tests with flying colours for donkey’s years. Typically the modified code works just fine, but you cannot actually test it without first eradicating the eighteen other near-identical bugs that have suddenly decided to start triggering, for no obvious reason other than the fact they too were all always obviously just waiting to go wrong. Not to be confused with a heisenbug: a bug that disappears when one attempts to study it. (A cute name but an incorrect reference. The quantum mechanical property of things changing when you observe them is the observer effect, not the Heisenberg uncertainty principle, however observereffectbug is simply just not as cute or funny.)