Re: Some questions about operators.
John Macdonald wrote:
if ($a xor $b xor $c) {...}
should succeed only when exactly one of ($a, $b, $c) is true.
That's not the definition of xor that I learned in school.
It's taking a simplified form of the definition that works
for two arguments and then expanding it to multiple
arguments - but the result is different from the original
definition of xor.
To which Paul Johnson added:
I think it is generally accepted that xor is true iff an odd nnumber of
its argumnets are true.
There are *two* generally accepted extensions of xor as an n-adic operator:
the one John learned in school, and the one Austin was describing. *Both* are
consistent with the definition of the binary form -- depending, of course, on
how the binary form is defined. ;-)
The parity version John described is the obvious extension of the binary
logic of an xor (as illustrated in John's truth-table). But it's at least
arguable that n-ary operators should not always be generated from binary ones
in this manner.
One could equally well argue that the binary xor truth table is really just a
convenient encoding of the semantics: exactly one of these operands is true.
And indeed many have done so, and thus generalized xor that way. For example,
this second definition is the basis of the exists uniquely (a.k.a. big-xor)
quantifier of predicate calculus.
And, indeed, that's how junctional xor (C^) is generalized in Perl 6 to
create the Cone function.
In practice, the parity-checking version of n-ary xor has proved extremely
useful in a number of practical low-level domains (low-level, at least,
compared to predicate calculus ;-). And that utility has meant that the
parity-checking definition has come to predominate.
But that doesn't make it the One True Xor, or even the best choice for a
high-level programming language.
Of course, I'm not going to argue that the various Perl 6 *bit-wise* xors
ought to be anything other than parity-checking, but the case for logical xor
isn't nearly so clear-cut.
Nor is exists uniquely the only alternative semantics. At an even higher
level, one could argue that xor means my operands all have different truth
values. Which implies that n-ary xor (for n2) should always return
false...unless, of course, we decide to implement Simon's 12 distinct boolean
values.
However I do think that, now we have Cone to carry the load of exists
uniquely, Larry will probably decide that Cxor is strictly binary, and
hence generalizes to the parity form in the n-ary case. I just don't want
people to think we neglected to consider the other valid alternatives.
Damian
Re: Some questions about operators.
On Tue, Mar 23, 2004 at 07:35:39AM +1100, Damian Conway wrote: : However I do think that, now we have Cone to carry the load of exists : uniquely, Larry will probably decide that Cxor is strictly binary, and : hence generalizes to the parity form in the n-ary case. Hmm, I probably will. :-) But I'd like to point out that there's also a view of xor as the negated form of BASIC's eqv, and that could be considered a comparison operator, and as we all know, comparison operators in Perl 6 do chaining. We can currently write eqv like this: ?$a == ?$b == ?$c which implies that we can write chained xor as: ?$a != ?$b != ?$c Of course, now someone's going to suggest that we should make ?^ a comparison operator so that you can just say $a ?^ $b ?^ $c And then go on to suggest that we also allow chained $a ? $b ? $c and $a ?| $b ?| $c And then they'll say, hey, if ? makes a true operator, we should also have the corresponding not true operators, giving us nand and nor directly: $a ! $b ! $c $a !| $b !| $c And then this person will point out that BASIC's eqv operator is just: $a !^ $b !^ $c And then, before this person can suggest anything else, he will be taken out and shot. :-) Larry
RE: Some questions about operators.
-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. Cxor 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 Czip.
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
Re: Some questions about operators.
Austin Hastings wrote:
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...
%hash = @keys @values;
Oh, and it's petaQ not pitaph.
Hey...wait a minute!
tlhInganHol
petaQ chopong?
bIQambogh DaqDaq qaHoH!!
/tlhInganHol
{{;-)
Damian
Re: Some questions about operators.
[EMAIL PROTECTED] (Austin Hastings) writes: I'm not sure that having quaternary logic in Perl 6 is necessarily a good idea. Why stop only at four states? Total about twelve possible states plus junctions, of which eight or nine would be 'useful', and only three would be knowingly used. Irony is wasted on perl6-language. -- A year spent in artificial intelligence is enough to make one believe in God.
RE: Some questions about operators.
-Original Message- From: Damian Conway [mailto:[EMAIL PROTECTED] Austin Hastings wrote: 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... %hash = @keys @values; Oh, and it's petaQ not pitaph. Umm, no. It's pitaph, vice japh. (Better than gdtsfhogwaph, certainly.) But you make my point. BTW, how did you generate that , or did you mouse it? =Austin
broken bar (Re: Some questions about operators.)
Dear All, I think that the broken bar is dangerous. Why: It can be mixed up with the normal bar |. In some fonts it looks the same. And to many people it is not 100% clear, which of the two bars is the broken one and which not. Off course it is possible to avoid this, but that is not solving the problem of reading perl-code that someone else has written. The «» are not such a problem. But I would think that it would still be worth considering to avoid the broken bar. Sorry if this disscussion has been performend 1000 times already. Best regards, Karl
Re: Some questions about operators.
At 9:19 PM + 3/20/04, Simon Cozens wrote: [EMAIL PROTECTED] (Austin Hastings) writes: I'm not sure that having quaternary logic in Perl 6 is necessarily a good idea. Why stop only at four states? Total about twelve possible states plus junctions, of which eight or nine would be 'useful', and only three would be knowingly used. Irony is wasted on perl6-language. And this is a new revelation? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: broken bar (Re: Some questions about operators.)
Well, maybe we should use yen (¥) instead. It even looks like a zipper. (Of course, we'll leave out the little problem that half the people in Japan would read it as a backslash wannabe...that's not really a problem since a zipper would only be used where an operator is expected, and backslash is illegal there (so far).) Larry
Some questions about operators.
I just read Synopsis 3, and I have several questions. 1) Synopsis 3 says that the difference between $x ?| $y and $x || $y is that the later always returns a Boolean. Does this mean that $x ?| $y short-circuits? 2) Do all of the xor variants have the property that chained calls return true if exactly one input parameter is true? 3) Is there an ASCII digraph for the | operator? 4) Do == and != participate in chained comparisons, so that $a == $b == $c evaluates to true if and only if all three are equal? Is $x $y $z a legal chaining? Or $x $y lt $z? 5) Would it be possible for me to create a user-defined operator that does chaining? Joe Gottman
Re: Some questions about operators.
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. Cxor is spelled out, and by definition XOR returns parity. On the other hand, the junctive ^ (one()) is exactly one. 3) Is there an ASCII digraph for the | operator? No. Just use Czip. 4) Do == and != participate in chained comparisons, so that $a == $b == $c evaluates to true if and only if all three are equal? Yes. But not really. It evaluates true if $a == $b and $b == $c (while only evaluating $b once). This may not be the same as all three being equal if $a, $b, and $c are objects whose equality isn't transitive. Is $x $y $z a legal chaining? Or $x $y lt $z? Sure. It (rather confusingly) asks whether $y is less than both $x and $z. The latter is too, and it's equivalent to: $x +$y and ~$y lt $z 5) Would it be possible for me to create a user-defined operator that does chaining? Yes. You just have to be clever about your return values. A comparison operator could return its right argument Cbut true or Cbut false. To get them to short circuit is exactly the same problem as getting other user-defined operators to short circuit, something that's been adressed but I don't remember the answer to. Luke
RE: Some questions about operators.
-Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Sent: Friday, 19 March, 2004 10:06 PM To: Joe Gottman Cc: Perl6 Subject: Re: Some questions about operators. 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. Cxor 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. 3) Is there an ASCII digraph for the | operator? No. Just use Czip. 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? It's like the old Far Side cartoon showing Ed's Dingoes right next to Martha's Day Care -- trouble waiting to happen. Let's pray nobody uses ... =Austin PS: S3 appears inconsistent WRT the . operator and hyperoperation. One example uses (f,oo,bar).length, while elsewhere you have @objects.run(); Comment?
Re: Some questions about operators.
Austin Hastings writes:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Friday, 19 March, 2004 10:06 PM
To: Joe Gottman
Cc: Perl6
Subject: Re: Some questions about operators.
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. Cxor 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.'
3) Is there an ASCII digraph for the | operator?
No. Just use Czip.
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 ?
It's like the old Far Side cartoon showing Ed's Dingoes right next
to Martha's Day Care -- trouble waiting to happen. Let's pray nobody
uses ...
=Austin
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.
Luke
