Trewth Seeker wrote: > Mark A. Biggar wrote: > > Trewth Seeker wrote: > > > In this case, we are dealing with '^^', a meaningless > > > unpronounceable symbol.
Caret caret. > > > Oh, but wait ... we also spell it 'xor', When reading code, it's probably read as xor, but when discussing syntax itself, I think caret caret is much more appropriate. > > > So what does that say about proposing that xor(p1,p2,...) is true > > > if an odd number of p[i] are true? Not much, I think. Logical xor doesn't make sense with more than two arguments. > > > Clearly, xor is true iff *exactly* one of its arguments is true, Yes, if(f?) exactly one of its TWO arguments is true. You both use "iff". What does that mean? > > > and of course it should return that argument (or bool::false if no > > > argument is true). How 'of course' is that? Lacking specification in Perl 6 documents, Perl 5's behaviour is the rule, and Perl 5 returns true or false, not the argument that was true, or false. I agree that it would be more useful if xor did indeed evaluate to the single true element if there is one (and only one). Perl 5's perlop says: "It cannot short circuit, of course." Can someone explain why it cannot? > > As long as you build "p1 xor p2 xor ..." out of binary xor ops that > > is the result you get. Computing parity is much more common that > > your multi-arg operation. Parity with logic xor? With bitwise xor, sure, agreed, that's the single most useful application of the bitop. But explain to me how you get some useful parity with xor'ed conditions? > Sorry, but you're quite wrong here, because that literature applies to > an associative operator, which Perl's xor is not. ((1 xor 2) xor 3) > == 3, while (1 xor (2 xor 3)) == 1. Pugs agrees. (1 xor 2 xor 3) is also 3. > and it ignores the context of the discussion in which it has been > noted that the value of "p1 xor p2" is either p1 or p2 or > bool::false, but not "true". Is this official yet? > My position is that it should either have its linguistic meaning, or > expressions of the form "p1 xor p2 xor p3" should be disallowed, since > there is no other natural meaning for it. bool::true is not an > acceptable result (unless one of p1, p2, or p3 is bool::true), and > simply picking one or the other of p1, p2, and p3 when they are all > true is arbitrary. All of which was obvious if you were to follow my > advice about problem solving. Anyone using chained logic xor booleanly expecting it to get true only if exactly one of the values is true, deserves punishment because they should be using a one() junction instead. Which, not entirely coincidentally, is available as &infix:<^> too, which looks suspicously like &infix:<^^>, don't you think? Anyone using chained logic xor for parity, ... hm, should explain to me how they use parity as a condition, because I don't quite yet grok the usefulness of this. Anyone using chained logic xor in another way should be punished for not using parens in a complex expression. (With and/or it's a minor offense, because they're much more common.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
