Mike Guy <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote
>> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
> has a different opinion then Parrot (or Perl6?).
> inline op xor(out INT, in INT, in INT) :base_core {
> $1 = ($2 && ! $3) ? $2 : ($3 && ! $2) ? $3 : 0;
> goto NEXT();
> }
>> We need language lawyers ;)
> IANAL, but I am a mathematician. Because C<xor> necessarily always
> depends on *both* its arguments, analogies with C<and> and C<or> are
> inappropriate. C<xor> cannot short-circuit, and it is not sensible
> to return as result either of the arguments.
C<xor> can't of course be short-circuit and above code isn't. Both values
are evaluated WRT trueness, always.
> ... So the above macro is misguided nonsense.
Not quite. It gives one value if one is true or 0 (false). This is more
information then the perl5 implementation returns. The returned value (if
any) is still true but usable, if I just want one of both. Well that's
"logical xor" - not binary xor.
> Perl5 C<xor> always returns a "standard" boolean value, i.e.
> dualvar(0, '') or dualvar(1, '1'). Perl6/Parrot should do the same
> thing.
Maybe, IANAL.
> Mike Guy
leo
