Atually there's an easier way to write xor:  if ( (COND1 and not COND2) or ((not COND1) and COND2) )

This way the conditions are evaluated less times (I think this is the easier way of expressing 'xor' in terms of 'and', 'or' and 'not')

While I agree that xor is a useful operation, there aren't that many places where it applies, as many situations rule themselves out in an or comparison.

For example, unless you are trying to model the rainbow, if ( $raining or $sunny ) contemplates the whole weather (simplified) model. Admitedly, in some cases the possibility arises: just use it. But as CPAN demonstrates, there aren't so many examples.

Now, if you are implementing a parser, or any complicated enough state machine...

Best regards,

--
our $Perl6 is Fantastic;

I use xor at a few places in the Regexp::Common test suite. I've two variables, one saying whether a regexp matched, and another saying whether the regexp should have matched. The test fails if one variable is true, the other false. Hence, an xor.

Abigail

That's an elegant solution, yessir!

Best regards,

--
our $Perl6 is Fantastic;

This way the conditions are evaluated less times

Eh? Not so.

$ perl -le 'print "T" if (print "foo" xor print "bar")'
foo
bar

$ perl -le 'print "T" if ((print "foo" and not print "bar") or (not pr
+int "foo" and print "bar"))'
foo
bar
foo
[download]

At best, the expanded version will result in the same number of evaluations.

-sauoq
"My two cents aren't worth a dime.";

Hi there,

I was, of course, talking about the first extended version offered by Abigail:

$  perl -le 'print "T" if ((print "foo" or print "bar") and (not (prin
+t "foo" and print "bar"))'
foo
foo
bar
[download]

More specifically, I was talking in the case A is false (messier to write with print() as a one liner, left as an exercise for the reader :-)

The point is, once you got the better, downlevel operator, use it if you need it! But no more than that.

best regards,

--
our $Perl6 is Fantastic;

Can you say that the internals of perl don't do the optimizations on user behalf? I'd hope that perl automatically thows out the expression w/o doing it fully if it finds out it's dead in the middle.

btw, your way is for those who don't have the concept, or truth table, memorized and reproduce it w/o thinking. Nothing wrong w/ it though.

Regardless, xor isn't something that is as easily applicapble such as, the plus operator or just the and operator.

Certain tools, for certain situations.

I am sure the Perl internals don't optimize a lot of things, specially in examples like Abigail showed us how to reduce the number of % operations by a careful use of user shortcuts (instead of depending in Perls shortcut for logical operators)

Well, actually, if I recall well, that's exactly the truth table for XOR:

A B  XOR
0 0   0
1 0   1
0 1   1
1 1   0
[download]

Ie. Either A is true and B is false, or B is true and it's A which is false. This form has the advantage over the other one than in the first part is true (ie. A and not B) there's no need to compute the second one (2 calculations, 1 per proposition). The first proposed form, which is a description of 'exclusive or' (ie. either A or B but not both at once) forces the evaluation of both parts (ie. Once proposition A and again A and proposition B to test the second one, which makes it 3. In the case it's neither A or B it shortcircuits sooner, that's right, and if A is false, then propositions A and B must be tested twice in both cases: it's a matter of taste, I guess).

And obviously I agree with you that XOR is pretty much more specialized than, say AND or PLUS...

OTOH, I'd love for Perl to implement a fast NAND (which by itself creates a complete Boolean algebra). BTW, nand doesn't make expressions easier to read, but much faster as it would shorcircuit much sooner in most cases...

Best regards,

--
our $Perl6 is Fantastic;

Because I have warnings turned on.

Abigail