Some questions about operators.
Joe Gottman
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
Luke Palmer
> 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.
>
> 3) Is there an ASCII digraph for the | operator?
No. Just use C<zip>.
> 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 C<but true> or C<but 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
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:lu...@luqui.org]
> 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. 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.
>
> > 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?
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?
Luke Palmer
> > -----Original Message-----
> > From: Luke Palmer [mailto:lu...@luqui.org]
> > 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. 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.'
>
> >
> > > 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 ¦ ?"
> 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
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:lu...@luqui.org]
> Austin Hastings writes:
> > > From: Luke Palmer [mailto:lu...@luqui.org]
> > > 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
Simon Cozens
I'm not sure that having quaternary logic in Perl 6 is necessarily a good
idea. Why stop only at four states?
--
... though the Japanese must be the most stupid people... I'm sure I
read somewhere that Tokyo has the densest population in the world...
- Gid Holyoake, sdm.
Damian Conway
> 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
Austin Hastings
> -----Original Message-----
> From: si...@alibi.simon-cozens.org
> [mailto:si...@alibi.simon-cozens.org]On Behalf Of Simon Cozens
>
> I'm not sure that having quaternary logic in Perl 6 is necessarily a good
> idea. Why stop only at four states?
Indeed:
undef, unset (disagreeable undef, a la NaN), nocare (always matches), true,
false. Plus "but tentative" and "but forcing" modifiers, and junction
support for 'none(true)'.
Total about twelve possible "states" plus junctions, of which eight or nine
would be 'useful', and only three would be knowingly used.
Most users would never see "nocare", and rarely see "unset." But NULL would
map directly to it (hello, DBI), the complex operators could use it, and
occasionally having the core logic code do the right thing would be a win,
like the xor example.
=Austin
Simon Cozens
> > I'm not sure that having quaternary logic in Perl 6 is necessarily a good
> > idea. Why stop only at four states?
>
> 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.
Austin Hastings
> -----Original Message-----
> From: Damian Conway [mailto:dam...@conway.org]
>
> 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
Damian Conway
>>Oh, and it's "petaQ" not "pitaph".
>
> Umm, no. It's "pitaph", vice "japh". (Better than "gdtsfhogwaph", certainly.)
Oh, then in that case:
<english>
You called me a "pain in the ass"?
I should kill you were you stand!!
</english>
;-)
> BTW, how did you generate that ¦, or did you mouse it?
I mapped one of my iBook's function keys to it.
Damian
Karl Brodowsky
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
Dan Sugalski
>Austin_...@Yahoo.com (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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
(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
John Macdonald
> 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:
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.
The truth table for xor is:
x y | x xor y
------+--------
0 0 | 0
0 1 | 1
1 0 | 1
1 1 | 0
If you look at the first two rows, the result is equalt to y:
zero xor'ed with y is y. The last two rows shot that one
xor'ed with y is the complement of y. Every 1 in a list of
values being xor'ed together complements the result. So:
$a xor $b xor $c
is true when either one or three of ($a, $b, $c) are true,
and false when zero or two of them are true. This
characteristic of xor gets used in many places: cryptography
and secure hash computations, for example, or RAID parity
value for another.
Since the one function already exists, there is no need to
change the meaning of the xor function.
Paul Johnson
Austin Hastings said:
> Let's look at boolean xor:
>
> if ($a xor $b xor $c) {...}
>
> should succeed only when exactly one of ($a, $b, $c) is true.
I think it is generally accepted that xor is true iff an odd nnumber of
its argumnets are true.
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Damian Conway
>> 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 C<one> 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 n>2) 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 C<one> to carry the load of "exists
uniquely", Larry will probably decide that C<xor> 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
Larry Wall
: However I do think that, now we have C<one> to carry the load of "exists
: 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