> -----Original Message-----
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Austin Hastings writes:
> > > From: Luke Palmer [mailto:[EMAIL PROTECTED]
> > > Joe Gottman writes:
> > > > 2) Do all of the xor variants have the property that
> > > > chained calls return true if exactly one input
> > > > parameter is true?
> > >
> > > I would imagine not. C<xor> is spelled out, and by
> > > definition XOR returns parity. On the other hand,
> > > the junctive ^ (one()) is exactly one.
> >
> > Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This
> > would involve returning something like a.or.b but a.xor.b.
>
> I don't know what you're hoping for when you say 'hope.'
Let's look at boolean xor:
if ($a xor $b xor $c) {...}
should succeed only when exactly one of ($a, $b, $c) is true. This corresponds roughly
to constructing and then collapsing a one() junction:
if one (?$a, ?$b, ?$c) {...}
If XOR is true, it should return 1/true. If XOR is false, it can either be "false, but
not preclusive of later success", or "definitely false". (Remember a year ago when we
talked about how many values should be present in a logical type?)
So "definitely false" xor "anything" is false.
But "tentatively false" is 0/false. It passes into another XOR just fine.
Thus:
tentatively false = 0
definitely false = 1/false. (or perhaps false/1 ?)
So
sub infix:xor(Scalar $a, Scalar $b) {
my $left = (?$a == ?($a.value)) ?? ?$a :: 1; # 0/true is true,
my $right = (?$b == ?($b.value)) ?? ?$b :: 1; # 1/false is 1
if ($left && $right) { return 1 but false; }
if ($left || $right) { return 1; }
else return 0;
}
means that:
0 xor 0 == 0
0 xor 1 == 1
1 xor 0 == 1
1 xor 1 == 1/false (!!)
so that:
(1 xor 1) xor 0 == 0
(1 xor 1) xor 1 == 1/false
Ad infinitum.
> > > > 3) Is there an ASCII digraph for the | operator?
> > > No. Just use C<zip>.
> >
> > Re: | vs Â
> >
> > Boggle! Who let that slip in?
> >
> > I kind of got the impression he was asking about e.g., ??! or some
> > such, a la ANSI C. (In the same vein as << for Â, etc.)
> >
> > But no, it's far worse: every keyboard that is capable of generating
> > '|' is labeled incorrectly. How's that for the principle of least
> > surprise?
>
> I've never been too fond of the (lack of) visual distinction between |
> and  . They're just too similar. I'd much rather see something like
> U+299A VERTICAL ZIGZAG LINE (â). But alas, not in latin-1 (not to
> mention my terminal's inability to render that character, but that
> wasn't a design constraint last time I checked Â-).
>
> But context serves us humans well here. Very infrequently will you see:
>
> for @a | @b -> $a, $b {...}
>
> My head hurts just thinking about what that actually does. Among other
> things, it should probably issue a warning saying "did you mean  ?"
Granted. But some pitaph is going to come along and find a novel new use for zip
outside of loops. And then it's going to be in an expression of some kind, where the
parser won't know what to do...
Ah, well, that's what P6tidy will be for. That program's going to have a hella-long
configuration setup...
> > PS:
> >
> > S3 appears inconsistent WRT the . operator and hyperoperation. One
> > example uses ("f","oo","bar")Â.Âlength, while elsewhere you have
> > @objectsÂ.run();
>
> Oops. The latter is correct.
I saw something a while back from $Larry talking about some consensus leaning towards
always being balanced. Is that a misrecollection on my part, or was there some
counterexample which actually provides value for  xor  xor  ?
=Austin
