Fwd: Re: Pugs 6.2.0 released.

--- Trewth Seeker <trewth...@yahoo.com> wrote:

> Date: Fri, 6 May 2005 13:15:37 -0700 (PDT)
> From: Trewth Seeker <trewth...@yahoo.com>
> Subject: Re: Pugs 6.2.0 released.
> To: "Mark A. Biggar" <ma...@biggar.org>
> CC: perl6-c...@perl.org
>
>
> --- "Mark A. Biggar" <ma...@biggar.org> wrote:
> > trewth...@yahoo.com wrote:
> >
> > > I see here another case of a common erroneous approach to
> > > problem-solving. People are trying to enumerate definitions
> to
> > impose
> > > on something, rather than starting with the thing at hand and
> > > exhausting any clues it may provide before moving on. This can
> > lead to
> > > serious and, in hindsight, embarrassing mistakes.
> > >
> > > In this case, we are dealing with '^^', a meaningless
> > unpronounceable
> > > symbol. Oh, but wait ... we also spell it 'xor', which I
> suppose
> > is
> > > often pronounced "ex or", which might be the source of the
> > difficulty.
> > > Because 'xor' stands for ... ... 'exclusive or'. Exclusive?
> > It's not
> > > hard to figure out what that means. Here are some of the
> > relevant
> > > dictionary definitions:
> > >
> > > Not allowing something else; incompatible: mutually
> exclusive
> > > conditions
> > > Not accompanied by others; single or sole
> > >
> > > So what does that say about proposing that xor(p1,p2,...) is
> true
> > if an
> > > odd number of p[i] are true? Other than that people should
> > pronounce
> > > these operators out loud more often?
> > >
> > > Clearly, xor is true iff *exactly* one of its arguments is
> true,
> > and of
> > > course it should return that argument (or bool::false if no
> > argument is
> > > true).
> > >
> > > That should now be so blatantly obvious that everyone should be
> > > embarrassed for not having seen it immediately. But don't run
> > from
> > > embarrassment (or become defensive and attack the messenger) --
> > it's a
> > > powerful tool (which is why we evolved to have it). It should
> > cause
> > > one to question one's thought processes and consider how to
> > improve
> > > upon them, which is all to the good, isn't it?
> >
> > Except that xor or ^^ is only a binary operation, there is no
> > "xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only
> be
> >
> > understood if you add () to disambiguate the order that the
> binary
> > ops
> > are performed. Fortunately, xor is associative so it doesn't
> > matter how
> > you add the (), you get the same answer. Try it out, you will
> > discover
> > that "p1 xor p2 xor ..." is true iff an odd number of the p's are
> > true.
> > 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. Besides, all the literature about logic and
>
> > circuit design define "p1 xor p2 xor ..." in terms of binary xor,
> > so
> > your trying to buck hundreds of years of consensus.
>
> 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. I again ask that you pay
> more
> attention to the thing you're dicussing, rather than to simply
> generate stuff out of your own head, so as to avoid trivial
> embarrassing error. You wrote q(Try it out, you will discover that
> "p1 xor p2 xor ..." is true iff an odd number of the p's are true)
> --
> this fails on two counts; 1) it begs the question, which was how
> "p1
> xor p2 xor p3" should be evaluated -- it can only be "tried out" if
> that answer has already been decided upon; 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".
>
> The literature on logic design treats n-ary exclusive xor as
> modular
> arithmetic, which is natural to do since it is an associative
> operator. But it provides no guidance as to the value of "1 xor 2
> xor 3", nor do your remarks, starting out with your claim that
> there
> is no "xor(p1,p2,...)". The language is being defined, so such
> claims are meaningless; there is no reason why xor cannot be an
> n-ary
> function. 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.
>
> -- ts
>
>
>
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour:
> http://tour.mail.yahoo.com/mailtour.html
>
>

__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail

Trewth Seeker wrote:
> Mark A. Biggar wrote:

> > > which I supppose is often pronounced "ex or", which might be the

> ---

(signatures removed)

Caret caret.

When reading code, it's probably read as xor, but when discussing syntax
itself, I think caret caret is much more appropriate.

Not much, I think. Logical xor doesn't make sense with more than two
arguments.

Yes, if(f?) exactly one of its TWO arguments is true.

You both use "iff". What does that mean?

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?

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?

Pugs agrees. (1 xor 2 xor 3) is also 3.

Is this official yet?

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

On the other hand, one(...) semantics can short circuit false as
soon as you find two trues, except that one(...) is not guaranteed
to execute in any particular order, whereas I think xor and ^^
should be make list associative but execute left-to-right, short
circuiting on the second true discovered, so you have some hope of
ordering the harder conditions later in a sequence and bypassing them.
In either case the one true value is returned. This seems to me to
be the most useful semantics. Presumably one could also get ordered
tests like this:

$trueone = infix:<xor> map { $_ = '' unless /foo/ } =$fh;

and return the one line in $fh that contains "foo", bombing out immediately
if there are two such lines. (I'm assuming infix:<xor> can be called
as a list operator there...)

Parity XOR is fine for +^, ~^, and even ?^, of course.

Larry

I was confused. It is entirely obvious why it can't.

Jonathan

Yes, but that doesn't explain what it means. Rather than me try to
explain it (poorly)...

http://en.wikipedia.org/wiki/If_and_only_if

David

Rob