Re: XOR does not work that way.

[Jon Lang]

Take a look at the page to which Damian provided a link.  You'll find
that XOR does indeed correspond to the definition being used by Perl
6, as well as the natural language meaning.  What other languages call
XOR is actually an "odd parity check".

As I suggested above, I think that Perl 6 already addresses both of
these: use '^' or 'xor' (or 'one()') if you want XOR semantics; use
'?^' if you want "odd parity" semantics.

> I suggest that to aid learnability, Perl 6 has the same semantics for 'xor'
> as other languages with that operator, unless there is a good explicit
> reason to do differently; that is, don't do differently just for the heck of
> it.

We never do things differently for the heck of it.

-- 
Jonathan "Dataweaver" Lang

Re: XOR does not work that way.

[Darren Duncan]

Mark J. Reed wrote:

All of which is just by way of agreeing with Jon: formal logic is not
the primary motivator behind Perl's design. So while it should be
considered, it's not a knockout punch to say "but logic doesn't work
that way."


I think another thing to consider is a survey of the various other common 
languages and see what semantics they have with an expression like this pseudocode:


  true xor true xor true

I would like to know in what languages the above expression is false ... or 
true.

I suggest that to aid learnability, Perl 6 has the same semantics for 'xor' as 
other languages with that operator, unless there is a good explicit reason to do 
differently; that is, don't do differently just for the heck of it.


I submit that Perl 5 appears to result in true, as tested with:

  perl -e "print (5 xor 2 xor 3)"

... which returns 1, indicating also that Perl 5 xor doesn't short-circuit.

Regardless of the above, I think Perl 6 should have both operators, testing 
exactly 1 or an odd number.


-- Darren Duncan

Re: XOR does not work that way.

[Mark J. Reed]

> On Mon, Jun 22, 2009 at 4:12 PM, Minimiscience wrote:
> I don't think natural language -- especially the abomination that is English
> -- is the best guide for understanding logical operations (why, yes, I *do*
> speak Lojban; how did you know?).

To which Jon Lang replied:
> You're aware that Perl was designed by a linguist, with an eye toward
> incorporating natural language concepts, right?

Let me make a small digression to expand upon what Jon said.

There's a reason natlangs don't work like loglangs: human thought
isn't based on logic.  Instead, logic is an artificial construct
which, while quite useful within its domain, is not necessarily
optimal for communicating with humans - not even when the other end of
the communication is a computer.  Computers are built around logic, of
course.  But while traditional programming was based on teaching
humans to think like the computer, the progression from machine code
to assembly to ever-higher-level languages has been about making the
computers accept programming languages with increasingly natural human
language features.  Perl has synonyms (TMTOWTDI), homonyms (context,
MMD), other sorts of ambiguity just like natlangs. (And no need to
pick on poor English especially; it's a perfectly cromulent language,
however suboptimal it might be from an auxlang or loglang
perspective.)

All of which is just by way of agreeing with Jon: formal logic is not
the primary motivator behind Perl's design. So while it should be
considered, it's not a knockout punch to say "but logic doesn't work
that way."


-- 
Mark J. Reed 

Re: XOR does not work that way.

[Jon Lang]

On Mon, Jun 22, 2009 at 4:12 PM, Minimiscience wrote:
> On Jun 22, 2009, at 5:51 PM, Damian Conway wrote:
>>
>> Perl 6's approach to xor is consistent with the linguistic sense of
>> 'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
>> with the IEEE 91 standard for logic gates.
>
> I don't think natural language -- especially the abomination that is English
> -- is the best guide for understanding logical operations (why, yes, I *do*
> speak Lojban; how did you know?).  As for consistency, Perl 6's bitwise
> exclusive-or operators follow the mathematical meaning of XOR, so using the
> "exactly one true value" definition for ^^ and xor would make Perl 6
> inconsistent with itself.

You're aware that Perl was designed by a linguist, with an eye toward
incorporating natural language concepts, right?

As for the bitwise xor: I consider the "inconsistency" between it and
the logical xor to be a feature, not a bug.  Mind you, it's a feature
that needs to be made apparent; but it's a feature nonetheless.
Specifically, it gives you a simple way of choosing which semantics
you wish to use: '^' gives you the natural language semantics, while
'?^' gives you the mathematical semantics.  This gives the programmer
an easy way of choosing which semantics he wants to use.

> I was going to say more in support of adding a separate operator for
> "exactly one true value," but Darren Duncan beat me to it.

Well, we already have "one" to mean "exactly one true value".

-- 
Jonathan "Dataweaver" Lang

Re: XOR does not work that way.

[Minimiscience]

On Jun 22, 2009, at 5:51 PM, Damian Conway wrote:

Perl 6's approach to xor is consistent with the linguistic sense of
'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
with the IEEE 91 standard for logic gates.


I don't think natural language -- especially the abomination that is  
English -- is the best guide for understanding logical operations  
(why, yes, I *do* speak Lojban; how did you know?).  As for  
consistency, Perl 6's bitwise exclusive-or operators follow the  
mathematical meaning of XOR, so using the "exactly one true value"  
definition for ^^ and xor would make Perl 6 inconsistent with itself.


I was going to say more in support of adding a separate operator for  
"exactly one true value," but Darren Duncan beat me to it.


-- Minimiscience

Re: XOR does not work that way.

[Darren Duncan]

Damian Conway wrote:

Perl 6's approach to xor is consistent with the linguistic sense of
'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
with the IEEE 91 standard for logic gates. See:

http://ozark.hendrix.edu/~burch/logisim/docs/2.1.0/libs/gates/xor.html

for a concise explanation of both these senses of xor.


I think that, where such a definition makes sense, any N-adic operation in Perl 
6 that would often be defined as a reduction operator / a repetition of dyadic 
operations should have those semantics, and any other behaviors shouldn't be the 
default, but be given some other less ambiguous name if useful.


And so, an N-adic xor should result in true (or one of its true operands) iff an 
odd number of its inputs is true.  And also, this operator can't short-circuit. 
 However, it could be reasonably assumed that either the first or the last true 
operand is what is always returned when any is returned; as for which one, I 
suggest using the same semantics as 'or', meaning the first, since 'xor' is a 
lot like 'or' in other ways such as its identity value.


If you want an N-adic operator that results in true (or its true operand) iff 
exactly one of its inputs is true, then that should be called something else.  I 
suggest calling it one(), or if that's confusing due to some junction operator, 
then maybe single() or something else.


In fact I would argue it is useful to have both operators, one that's true for 
an odd number of true inputs, and one that's true for exactly one true input. 
If the name 'xor' is so touchy, then maybe don't use that name at all, and just 
use say 'odd' and 'one' etc.  On a tangent, maybe an 'even' operator would be 
useful too.  This said, assuming you're going for 2 versions of everything, one 
high and one low precedence, I have no opinion as to whether ^^ goes to 'odd' or 
'one', since AFAIK that isn't a standard symbol for the op from math anyway.


-- Darren Duncan

Re: XOR does not work that way.

[Damian Conway]

Perl 6's approach to xor is consistent with the linguistic sense of
'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
with the IEEE 91 standard for logic gates. See:

http://ozark.hendrix.edu/~burch/logisim/docs/2.1.0/libs/gates/xor.html

for a concise explanation of both these senses of xor.

Damian

Re: XOR does not work that way.

[yary]

I had a bit of a problem when first encountering xor with more than
two operands as well. It made sense after I thought about it
linguistically instead of mathematically. When speaking people often
use a string of "or"s to mean "pick one and only one of these choices,
the the exclusion of all others".

Also I suspect that perl6's linguistic interpretation of "xor" (only
one true item in list) will be more useful to programmers than a
mathematical reductionist interpretation (odd number of true items in
list).

I think a note explaining the reasoning behind perl6's behavior on
exclusive-or with >2 items ought to go in the synopsis, as it's bound
to come up again.

XOR does not work that way.

[Minimiscience]

S03 describes ^^ as a "short‐circuit exclusive‐or" operator which  
returns true if & only if exactly one operand is true, short  
circuiting after encountering two true values.  However, this  
definition is only consistent with the mathematical definition of XOR  
when the operation is being performed on no more than two operands,  
yet ^^ has list associativity, implying that the Synopsis's  
specification applies regardless of how many expressions are being  
XORed together at once.  Moreover, assuming that S03's definition only  
refers to XOR with two operands would make the specification seem very  
poorly written, and short-circuiting would not accomplish anything at  
all.


Under the mathematical definition, a series of boolean values chained  
together (for lack of a better term) with XOR associate such that the  
result of a single XOR pairing is passed as an operand to the adjacent  
XOR.  (Because XOR is associative in the mathematical sense, treating  
it as either left-associative or right-associative will always produce  
the same result.)  It can be shown that the truth of the entire  
expression is *not* equivalent to whether there is exactly one true  
operand but rather to whether the number of true operands is odd (cf.  
"1 ^ 1 ^ 1" in C or Perl 5).  Thus, in order to determine the truth  
value of such a series, the truth value of *every* operand needs to be  
evaluated, and so it is impossible to short-circuit.  (Interestingly,  
assuming that it processes two operands at a time, the reduce operator  
[^^] implements XOR correctly for more than two operands, even if  
plain ^^ does not.)  An operator which returns true if & only if  
exactly one of its operands is true would be a separate operation  
entirely; the closest thing I can find in mathematics (OK, on  
Wikipedia) is the minimal negation operator  when its arguments have been mapped through a logical NOT.


This problem also applies to the description of the "xor" operator,  
though not to the bitwise XOR operators, as they make no claims to  
unorthodox behavior and the proper behavior can be inferred from the  
fact that they are left-associative.  The appropriateness of the ^  
junctive operator is less clear, however; while the synopses don't  
seem to refer to it as an exclusive-or operation (though I could be  
wrong about that), and its list associativity allows it to be viewed  
as wrapping a "one()" function around all of its operands, its  
similarity in spelling to ^^ and the bitwise XOR operators (especially  
the historical one) could be problematic.


To summarize: either bring ^^ and xor with more than two operands in  
line with the mathematical definition (possibly by just making them  
left-associative and rewriting the descriptions to match), or stop  
calling them "exclusive or."


-- Minimiscience