and and or return the last expression evaluated; xor always evaluates both sides and then returns the exclusive or of those two expressions (not either of the surrounding expressions) so it's always going to be a boolean value either 1 or ''/0. See perlop

Update: On further reflection I think I see what your expectations for the behavior might be based on and/or's behavior: if A xor B is true return whichever of A or B was true, otherwise return false.

In perlop I find that 'Binary "and" returns the logical conjunction of the two surrounding expressions.', not 'the last expression evaluated'. So maybe I misinterpret here? Or maybe text of docs here needs to be improved.

It's further down under the heading "Logical Defined-Or" (so yes, it's disjoint from the other discussion of && above it):

    The "||", "//" and "&&" operators return the last value evaluated 
+(unlike
    C's "||" and "&&", which return 0 or 1). Thus, a reasonably portab
+le way
    to find out the home directory might be:
[download]

The cake is a lie.
The cake is a lie.
The cake is a lie.

That's the feature of short circuit and and or which can't be replicated with xor

Grandfather and ikegami already explained it perfectly.

>> Binary "and" returns the logical conjunction of the two surrounding expressions.

It's not much about short-circuit, but more about logical return value? I understand 'logical' as being Boolean, i.e. 1 or ''/0. So if an operator doesn't return a boolean value then this should be emphasized, and the sentence about return value rather should be corrected.

regarding "Boolean", see "Scalar values" in perldata:

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.

You seem to think upon a "really" boolean datatype with exactly two distinct values. This is not the case here.

Perl has no Boolean type, it is interpreting values in boolean context, (which is a specialized scalar context).

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)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

No, that's completely wrong. The reason $TRUE and $TRUE doesn't necessarily return 1 has nothing to do with why $TRUE xor $TRUE doesn't return 1.

$TRUE and $TRUE doesn't necessarily return 1 because it's more useful to return its RHS.

$TRUE xor $TRUE doesn't return 1 because that would be wrong.