A scalar value is interpreted as FALSE in the Boolean sense if it is undefined, the null string or the number 0 (or its string equivalent, "0"), and TRUE if it is anything else. The Boolean context is just a special kind of scalar context where no conversion to a string or a number is ever performed. Negation of a true value by ! or not returns a special false value. When evaluated as a string it is treated as "" , but as a number, it is treated as 0. Most Perl operators that return true or false behave this way.

There are only two default scalars 1 and ""/0 (i.e. !!1 and !!0) in case a Boolean result needs to be generated, like when using not (sic)

The extra behaviour of and/or to return the last evaluated side is closely related to short circuiting, and will by definition lead to a appropriate scalar again.

AFAIK is this feature boroughed from C, but can't be possibly extended to not or even xor

Update

That's easily proven by translating xor to a term based on and/or, since this can't be done without not

A xor B := ( A and not B) or ( B and not A)

Besides inconsistencies it's also not well defined, because the two sides of the and/or terms can be swapped (commutativity)

>> A xor B := ( A and not B) or ( B and not A)

I only want to leave here an example: although 'logically' they return the same 'Perl-truthness', in this case they won't return same value:

perl -wle 'my( $A, $B ); print for map "[$_]", ( $A xor $B ), ( $A and
+ not $B or $B and not $A ); '
[download]

output ('' vs. undefined):

Use of uninitialized value $_ in concatenation (.) or string at -e lin
+e 1.
[]
[]
[download]