Pugs 6.2.0 released.

2 views
Skip to first unread message

Autrijus Tang

unread,
Apr 12, 2005, 3:50:38 PM4/12/05
to perl6-c...@perl.org, perl6-l...@perl.org, perl6-i...@perl.org
I am delighted to report that the first major milestone of Pugs, version
6.2.0, has been released to CPAN:

http://wagner.elixus.org/~autrijus/dist/Perl6-Pugs-6.2.0.tar.gz
SIZE (Perl6-Pugs-6.2.0.tar.gz) = 642482
MD5 (Perl6-Pugs-6.2.0.tar.gz) = 8d5438d49db872ffe2394fd4995d335b

It represents the culmination of 71 days of intensive work, by more
than 60 people in our committer team, with nearly 2000 revisions.

According to the roadmap in PA01, this and the next milestone are:

6.2: Basic IO and control flow elements; mutable variables; assignment.
6.28: Classes and traits.

In other words, we are now reasonably confident that the basics of
Perl 6 syntax and data structures are in place. We already have an
object/type system now, and the 6.2.x series will make them available
on the language leve, together with a full-fledged class system.

After this release, I will take a short break from coding Pugs, and
focus on writing "Pugs Apocryphon 2: Design of Pugs". In it I will
explain the relation of the various components in Pugs, as well as how
it relates to Parrot, GHC, and other systems. Once it is written,
I plan to start working on the IMC subsystem, with the goal of making
Parrot IMC the primary target for the 6.28.0 release.

Again, thanks too all lambdacamels for making this release possible,
and for building this new ship with me.

Enjoy,
/Autrijus/

== Changes for 6.2.0 - April 13, 2005

=== Pugs Internals

* Major refactor of ITypes subsystem, we now have:
** Nested structures: `$a{1}[2]{3}`
** Autovivification: `$a{1}[2]{3} = <b>`
** Tied magic: `%ENV<USER>`
** Proxy scalars: `%ENV<PATH> ~= '/tmp'`
** Slice assignment: `@x[1,2] = <a b>`
** Anonymous arrays: `[1..10][0] = 0`
** Lazy IArray structures: "Infinite lists, constant time"
** Infinite slices: `@x[1...]`
** and much much more ...
* Experimental support for link external Haskell libraries
** One such module is SHA1.pm: http://tpe.freepan.org/repos/ingy/SHA1/
* New builtins:
** `sum`, `log`, `log10`, `sign`, `pi`, `tan`, `cos`, `atan`
** `zip`, `hash`, `pair`, `isa`, `bytes`, `chars`, `codes`, `graphs`
* New type specific builtins;
** `.kv`, `.pairs`, `.delete`, `.exists`
** `.pick`, `.keys`, `.values`
* Several file test operators
** `-r`, `-w`, `-x`, `-e`, `-z`, `-s`, `-f`, `-d`
* Support for `$*UID`, `$*EUID`, `$*GID`, and `$*EGID` on *nix
* Stacked file test operators now (mostly) work
* Added `is rw` trait for subroutine parameters
* `$*PID` now works on *nix systems
* Several command line switches implemented: `-I` `-p` `-n` and more
* `s:perl5/.../{ <code> }/` works correctly
* Type casting errors are now more descriptive
* `require ""` now works on UTF-8 files
* Regex substitution is now UTF-8 safe
* `sort {}` now works
* Some support for the /splat/ star `*`

=== Tests, Examples and Documentations

* Many new tests and cleaning up of older tests, we now have 4200+
* `examples/games/hangman.p6` added which uses the `AUTHORS` file as
the dictionary file
* `READTHEM` added; recommended reading for aspiring Pugs hackers
* The Perl 6 Cookbook is well underway at `examples/cookbook/`
* Working perl6 modules added to `ext/`
** CGI.pm
** lib.pm
** HTML::Entities
* Several Working Drafts added to `docs/`
** Apocalypse 20 - Debugging
** Synopsis 26 - Perl Documentation
** Synopsis 28 - Special Variables
** Synopsis 27 - Perl Culture (with CPAN drinking game rules)
** Synopsis 29 - Builtin Functions
* Early work on Perl 6 Object System in `docs/class/`

=== Bug Fixes

* Parens no longer required for; `last()` and `return()`
* Fixed issue with binding invocant parameters
* Fixed parsing issue with `lc $, $y`
* `$_` now behaves correctly in most cases
* `exit()` now triggers `END {}` correctly
* `undef $x` now works correctly ($x is rw)
* Fixed parsing of default parameters: `sub foo (+$x = 3, +$y = 4)`
* `say` and `print` now default to `$_`
* `map { ... } @list` now parses correctly
* `loop { ... }` no works correctly
* `int(3) + 4` now parses correctly
* Fix parsefail bug on false unaries
* `for (@list)` no longer flattens `@list`
* `$var.method $param` is now illegal: use `$var.method($param)`
* `readline()` is now strict in list context
* `$list.join('|')` now works
* `xor` and `^^` now short-circuits
* Named bindings to `%_` repaired

Matt Fowles

unread,
Apr 12, 2005, 4:15:35 PM4/12/05
to Autrijus Tang, perl6-c...@perl.org
Autrijus~

On Apr 12, 2005 3:50 PM, Autrijus Tang <autr...@autrijus.org> wrote:
> * `xor` and `^^` now short-circuits

How does this work? I thought xor /had/ to evaluate both sides.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???

Andrew Savige

unread,
Apr 12, 2005, 7:18:52 PM4/12/05
to Matt Fowles, Autrijus Tang, perl6-c...@perl.org
--- Matt Fowles <uber...@gmail.com> wrote:
> Autrijus~
>
> On Apr 12, 2005 3:50 PM, Autrijus Tang <autr...@autrijus.org> wrote:
> > * `xor` and `^^` now short-circuits
>
> How does this work? I thought xor /had/ to evaluate both sides.

It does. At least according to "Perl 6 and Parrot Essentials" book,
page 36 it does (I couldn't find details on xor operator in S03).
I added some xor tests which Autrijus fixed. I'm worried now that
my tests may be wrong. On page 36 it says: "it returns the value
of the true operand if any one operand is true".

# cat f.p6
my $x = 0 ^^ 42;
print "x='$x'\n";
$x = (0 xor 42);
print "x='$x'\n";

# pugs f.p6
x='42'
x='42'

Is this correct behaviour? (Pugs used to print not '42' but '1').

/-\


Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Luke Palmer

unread,
Apr 12, 2005, 7:43:04 PM4/12/05
to Andrew Savige, Matt Fowles, Autrijus Tang, perl6-c...@perl.org
Andrew Savige writes:
> --- Matt Fowles <uber...@gmail.com> wrote:
> > Autrijus~
> >
> > On Apr 12, 2005 3:50 PM, Autrijus Tang <autr...@autrijus.org> wrote:
> > > * `xor` and `^^` now short-circuits
> >
> > How does this work? I thought xor /had/ to evaluate both sides.
>
> It does. At least according to "Perl 6 and Parrot Essentials" book,
> page 36 it does (I couldn't find details on xor operator in S03).
> I added some xor tests which Autrijus fixed. I'm worried now that
> my tests may be wrong. On page 36 it says: "it returns the value
> of the true operand if any one operand is true".
>
> # cat f.p6
> my $x = 0 ^^ 42;
> print "x='$x'\n";
> $x = (0 xor 42);
> print "x='$x'\n";
>
> # pugs f.p6
> x='42'
> x='42'
>
> Is this correct behaviour? (Pugs used to print not '42' but '1').

Ahh, so it returns the correct value. It's not short-circuiting
because, for example, in this expression:

a() xor b()

There is no value that a() (or b()) could return that would supress the
evaluation of the other.

Luke

John Macdonald

unread,
Apr 12, 2005, 8:27:33 PM4/12/05
to Andrew Savige, Matt Fowles, Autrijus Tang, perl6-c...@perl.org
On Tuesday 12 April 2005 19:18, Andrew Savige wrote:
> It does. At least according to "Perl 6 and Parrot Essentials" book,
> page 36 it does (I couldn't find details on xor operator in S03).
> I added some xor tests which Autrijus fixed. I'm worried now that
> my tests may be wrong. On page 36 it says: "it returns the value
> of the true operand if any one operand is true".

The mathematical definition of xor for two arguments is "true if
exactly one argument is true, false otherwise". When that gets
generalized to multiple arguments it means "true if an odd number
of the arguments are true, false otherwise". So, you cannot short
circuit the evaluation because any value, if it happens to be true,
changes the result of the expression. However, with perl's usual
flexibility for the value "true" you could choose the first or last true
value as the result if there were an odd number of true values, I
suppose, but returning last true (or false) makes more sense.
(Using the first is essentially the same as making xor right associative
instead of left.)

Darren Duncan

unread,
Apr 12, 2005, 8:45:24 PM4/12/05
to perl6-c...@perl.org
At 8:27 PM -0400 4/12/05, John Macdonald wrote:
>The mathematical definition of xor for two arguments is "true if
>exactly one argument is true, false otherwise".

Yes.

>When that gets
>generalized to multiple arguments it means "true if an odd number
>of the arguments are true, false otherwise".

Is this the official mathematics position?

If not, I would generalize it like this: true If >= 1 arg is true
and >= 1 arg is false, otherwise false.

Is that better or worse?

> So, you cannot short
>circuit the evaluation because any value, if it happens to be true,
>changes the result of the expression.

If my assertion is used, then all you can short circuit once you find
a true value and a false value.

Of course, we should go with what the official mathematics standard is.

-- Darren Duncan

Luke Palmer

unread,
Apr 12, 2005, 9:00:51 PM4/12/05
to Darren Duncan, perl6-c...@perl.org
Darren Duncan writes:
> At 8:27 PM -0400 4/12/05, John Macdonald wrote:
> >The mathematical definition of xor for two arguments is "true if
> >exactly one argument is true, false otherwise".
>
> Yes.
>
> >When that gets
> >generalized to multiple arguments it means "true if an odd number
> >of the arguments are true, false otherwise".
>
> Is this the official mathematics position?

Naively, yes. And mathematics othen revels in the naive position (any
other would not be consistent):

xor(1, 0, 0, 1, 1, 0)
1 xor 0 xor 0 xor 1 xor 1 xor 0
1 xor (0 xor (0 xor (1 xor (1 xor 0))))
1 # parity 1, odd number of arguments true

> If not, I would generalize it like this: true If >= 1 arg is true
> and >= 1 arg is false, otherwise false.
>
> Is that better or worse?

I don't think that's what xor is testing. I can't quite think of why
you'd need that (but I can't quite think of why you'd need xor
either...).

Luke

John Macdonald

unread,
Apr 12, 2005, 9:15:13 PM4/12/05
to Darren Duncan, perl6-c...@perl.org
On Tuesday 12 April 2005 20:45, Darren Duncan wrote:
> At 8:27 PM -0400 4/12/05, John Macdonald wrote:
> >The mathematical definition of xor for two arguments is "true if
> >exactly one argument is true, false otherwise".
>
> Yes.
>
> >When that gets
> >generalized to multiple arguments it means "true if an odd number
> >of the arguments are true, false otherwise".
>
> Is this the official mathematics position?

It's simply chaining a series of 2-arg xor's together. As it happens, the
result of such chaining comes out as "odd number true" and has the nice
properties of being commutative [a xor b === b xor a] and associative
[((a xor b) xor c) === (a xor (b xor c))].

> If not, I would generalize it like this: true If >= 1 arg is true
> and >= 1 arg is false, otherwise false.
>
> Is that better or worse?

The "mathematical" definition can generalize down to one or zero
elements as well as up to n.

> > So, you cannot short
> >circuit the evaluation because any value, if it happens to be true,
> >changes the result of the expression.
>
> If my assertion is used, then all you can short circuit once you find
> a true value and a false value.

Well, it's a function that can be short circuited, but it's not xor and would
have different uses.

Patrick R. Michaud

unread,
Apr 12, 2005, 10:19:51 PM4/12/05
to Darren Duncan, perl6-c...@perl.org
On Tue, Apr 12, 2005 at 05:45:24PM -0700, Darren Duncan wrote:
> At 8:27 PM -0400 4/12/05, John Macdonald wrote:
> >The mathematical definition of xor for two arguments is "true if
> >exactly one argument is true, false otherwise".
>
> Yes.
>
> >When that gets
> >generalized to multiple arguments it means "true if an odd number
> >of the arguments are true, false otherwise".
>
> Is this the official mathematics position?
>
> If not, I would generalize it like this: true If >= 1 arg is true
> and >= 1 arg is false, otherwise false.

The above generalization is probably wrong. C<xor> and C<^^> are
analogous to C<or> and C<||> in that they can return one of their
operands as values, and not a boolean "true" value (unless of
course that happens to be one of the operands). The returns-a-boolean
form of xor is &infix:<?^> .

Thus:

$a = 0 ^^ 5; # $a == 5
$b = 7 ^^ 0; # $b == 7
$c = 7 ^^ 5; # $c == false or 0, could be argued either way
$d = 0 ^^ 0; # $d == 0

but what to do with

$e = 2 ^^ 4 ^^ 6; # $e == ??

One could treat it as

$e = 2 ^^ (4 ^^ 6); # $e == 2

or maybe

$e = (2 ^^ 4) ^^ 6; # $e == 6

or one could even be analogous to the one() junction (&infix:^)
such that

$e = 2 ^^ 4 ^^ 6; # $e == false or 0

> Of course, we should go with what the official mathematics standard is.

Only if someone can define what the "mathematics standard" is here
without saying that "xor returns 'true' or 'false'". (Of course, p6l
is allowed to trump us on this one.)

Pm

Patrick R. Michaud

unread,
Apr 12, 2005, 10:36:57 PM4/12/05
to John Macdonald, Darren Duncan, perl6-c...@perl.org
On Tue, Apr 12, 2005 at 09:15:13PM -0400, John Macdonald wrote:
> On Tuesday 12 April 2005 20:45, Darren Duncan wrote:
> > At 8:27 PM -0400 4/12/05, John Macdonald wrote:
> > >The mathematical definition of xor for two arguments is "true if
> > >exactly one argument is true, false otherwise".
> >
> > Yes.
> >
> > >When that gets
> > >generalized to multiple arguments it means "true if an odd number
> > >of the arguments are true, false otherwise".
> >
> > Is this the official mathematics position?
>
> It's simply chaining a series of 2-arg xor's together. As it happens, the
> result of such chaining comes out as "odd number true" and has the nice
> properties of being commutative [a xor b === b xor a] and associative
> [((a xor b) xor c) === (a xor (b xor c))].

It's entirely possible that I have my mathematics messed up here,
but C<xor> doesn't seem to me to be entirely associative, at least not
as I commonly think of associativity. Consider

$x = (((0 xor 2) xor 4) xor 6); # ((a xor b) xor c) == 6

$y = ((0 xor 2) xor (4 xor 6)); # (a xor (b xor c)) == 2

Pm

John Macdonald

unread,
Apr 12, 2005, 11:13:18 PM4/12/05
to Patrick R. Michaud, Darren Duncan, perl6-c...@perl.org

You're both messed up your math and you've mixed the boolean
xor function up with the extension of it to an array of bits that is used
for integer xor. When you xor integers, you are really xor'ing each
of the bit positions in the integers in parallel, using the boolean xor
function for each bit independently.

You can see the same boolean/integer difference in perl5 with:

(4&2) is 0
(4&&2) is 4

Meanwhile, with your example (using integer xor):


(((0 xor 2) xor 4) xor 6)

is ((2 xor 4) xor 6)
is (6 xor 6)
is 0

((0 xor 2) xor (4 xor 6))

is (2 xor (4 xor 6))
is (2 xor 2)
is 0

The same example, using boolean xor:

(((0 xor 2) xor 4) xor 6)

--> (((false xor true) xor true) xor true)
--> ((true xor true) xor true)
--> (false xor true)
--> true

((0 xor 2) xor (4 xor 6))

--> ((false xor true) xor (true xor true))
--> (true xor (true xor true))
--> (true xor false)
--> true

While boolean xor and integer xor give different results (just as boolean
and integer AND gave different results in my example above) they are
both perfectly associative.

The issue for perl, in the boolean xor case, is which particular true value
will be returned (I'd prefer 6 my self, simply by not changing the numbers
to true and false, but rather leaving them as their numerical values and then
having xor return the non-false value if there is exactly one, or returning
0 otherwise. However, *that* interpretation reduces the associativity
because adding parentheses can change which component value is returned
for a true result as shown by your example:

(((0 xor 2) xor 4) xor 6)

--> ((2 xor 4) xor 6)
--> (0 xor 6)
--> 6

((0 xor 2) xor (4 xor 6))

--> (2 xor (4 xor 6))
--> (2 xor 0)
--> 2

Both return a true value, but it is a different true value.

Patrick R. Michaud

unread,
Apr 12, 2005, 11:46:24 PM4/12/05
to John Macdonald, Darren Duncan, perl6-c...@perl.org
On Tue, Apr 12, 2005 at 11:13:18PM -0400, John Macdonald wrote:
> On Tuesday 12 April 2005 22:36, Patrick R. Michaud wrote:
> > It's entirely possible that I have my mathematics messed up here,
> > but C<xor> doesn't seem to me to be entirely associative, at least not
> > as I commonly think of associativity. Consider
> >
> > $x = (((0 xor 2) xor 4) xor 6); # ((a xor b) xor c) == 6
> >
> > $y = ((0 xor 2) xor (4 xor 6)); # (a xor (b xor c)) == 2
>
> You're both messed up your math and you've mixed the boolean
> xor function up with the extension of it to an array of bits that is used
> for integer xor. When you xor integers, you are really xor'ing each
> of the bit positions in the integers in parallel, using the boolean xor
> function for each bit independently.

No, I'm afraid I haven't messed up my math. Integer-xor is &infix:<+^> .
Array-of-bits-xor is &infix:<~^> . I'm specifically talking about
&infix:<xor>, which "Perl 6 and Parrot Essentials" says (p. 36):

The XOR relation ... returns the value of the true operand if any
one operand is true, and a false value if both are true or neither
is true.

It does *not* say that XOR returns "true", it says it returns
"the value of the true operand". (Note that this is different from p5,
which at least on my system does return true/false for C<xor>.)


> You can see the same boolean/integer difference in perl5 with:
>
> (4&2) is 0
> (4&&2) is 4

Yes, I know this difference. And in perl 6, the difference is

(4 +& 2) is 0
(4 && 2) is 4

(4 +^ 2) is 6
(4 ^^ 2) is false

> Meanwhile, with your example (using integer xor):
> (((0 xor 2) xor 4) xor 6)
> is ((2 xor 4) xor 6)
> is (6 xor 6)
> is 0

Integer xor is (((0 +^ 2) +^ 4) +^ 6) == 0.

> The same example, using boolean xor:
> (((0 xor 2) xor 4) xor 6)
> --> (((false xor true) xor true) xor true)
> --> ((true xor true) xor true)
> --> (false xor true)
> --> true

Boolean xor is (((0 ?^ 2) ?^ 4) ?^ 6) == 1.

> While boolean xor and integer xor give different results (just as boolean
> and integer AND gave different results in my example above) they are
> both perfectly associative.

Yes, boolean xor and integer xor are associative. But that's not what
I was talking about. In particular:

(((0 xor 2) xor "four") xor "six")
--> ((2 xor "four") xor "six")
--> (false xor "six")
--> "six"

> The issue for perl, in the boolean xor case, is which particular true value
> will be returned

The &infix:<xor> operator in perl 6 is not a "boolean" operator, it's
a low-level "logical" operator, same as &infix:<and> and &infix:<or>.
And C<xor> returns one of its arguments (or "false"), again the same that
C<and> and C<or> do. And within these constraints, I don't believe
that C<xor> is mathematically associative according to any of the
definitions offerred thus far.

Pm

Autrijus Tang

unread,
Apr 13, 2005, 1:11:53 AM4/13/05
to Matt Fowles, Autrijus Tang, perl6-c...@perl.org
On Tue, Apr 12, 2005 at 04:15:35PM -0400, Matt Fowles wrote:
> Autrijus~
>
> On Apr 12, 2005 3:50 PM, Autrijus Tang <autr...@autrijus.org> wrote:
> > * `xor` and `^^` now short-circuits
>
> How does this work? I thought xor /had/ to evaluate both sides.

That's what I get for staying up too late when writing the ChangeLog file.

That line now reads:

* `xor` and `^^` now returns the true operand instead of `bool::true`

Thanks,
/Autrijus/

John Macdonald

unread,
Apr 13, 2005, 7:15:48 AM4/13/05
to Patrick R. Michaud, Darren Duncan, perl6-c...@perl.org
On Tuesday 12 April 2005 23:46, Patrick R. Michaud wrote:
> On Tue, Apr 12, 2005 at 11:13:18PM -0400, John Macdonald wrote:
> > On Tuesday 12 April 2005 22:36, Patrick R. Michaud wrote:
> > > It's entirely possible that I have my mathematics messed up here,
> > > but C<xor> doesn't seem to me to be entirely associative, at least not
> > > as I commonly think of associativity. Consider
> > >
> > > $x = (((0 xor 2) xor 4) xor 6); # ((a xor b) xor c) == 6
> > >
> > > $y = ((0 xor 2) xor (4 xor 6)); # (a xor (b xor c)) == 2
> >
> > You're both messed up your math and you've mixed the boolean
> > xor function up with the extension of it to an array of bits that is used
> > for integer xor. When you xor integers, you are really xor'ing each
> > of the bit positions in the integers in parallel, using the boolean xor
> > function for each bit independently.
>
> No, I'm afraid I haven't messed up my math. Integer-xor is &infix:<+^> .
> Array-of-bits-xor is &infix:<~^> . I'm specifically talking about
> &infix:<xor>, which "Perl 6 and Parrot Essentials" says (p. 36):

Time for me to see the optometrist.

I could have sworn that your examples were returning 0 and 2, but
that's definitely a 6 up there. We're violently in agreement. The
"boolean" form of xor is associative about the true/false meaning
of what it returns, but non-associative about what actual value is
returned for true.

I apologize. You were not mixed up or messed up.

Patrick R. Michaud

unread,
Apr 13, 2005, 10:34:39 AM4/13/05
to John Macdonald, Darren Duncan, perl6-c...@perl.org
On Wed, Apr 13, 2005 at 07:15:48AM -0400, John Macdonald wrote:
> On Tuesday 12 April 2005 23:46, Patrick R. Michaud wrote:
> > No, I'm afraid I haven't messed up my math. Integer-xor is &infix:<+^> .
> > Array-of-bits-xor is &infix:<~^> . I'm specifically talking about
> > &infix:<xor>, which "Perl 6 and Parrot Essentials" says (p. 36):
>
> Time for me to see the optometrist.
>
> I could have sworn that your examples were returning 0 and 2, but
> that's definitely a 6 up there. We're violently in agreement. The
> "boolean" form of xor is associative about the true/false meaning
> of what it returns, but non-associative about what actual value is
> returned for true.
>
> I apologize. You were not mixed up or messed up.

Thanks, I can see it was an honest error. I've done the same. :-)

For clarity in future discussions, I'd suggest that we bear in
mind that perl 6 makes a distinction between "boolean xor" and
"logical xor". "Boolean xor" is officially &infix:<?^>, and
returns a true/false value based on the truth/falsity of its
arguments. "Logical xor" is &infix:<^^> (tight) or
&infix:<xor> (loose), and returns false if both arguments are true,
false if both arguments are false, or its non-false argument.

For completeness, from S03:

and or xor not
boolean &infix:<?&> &infix:<?|> &infix:<?^> &prefix:<!>
integer &infix:<+&> &infix:<+|> &infix:<+^> &prefix:<+^>
string &infix:<~&> &infix:<~|> &infix:<~^> &prefix:<~^>
logical tight &infix:<&&> &infix:<||> &infix:<^^>
logical loose &infix:<and> &infix:<or> &infix:<xor> &prefix:<not>

Pm

Trewth Seeker

unread,
May 3, 2005, 8:59:44 PM5/3/05
to perl6-c...@perl.org, perl-perl...@moderators.isc.org
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?

-- ts

Mark A. Biggar

unread,
May 4, 2005, 10:29:35 AM5/4/05
to trewth...@yahoo.com, perl6-c...@perl.org
trewth...@yahoo.com wrote:

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.

--
ma...@biggar.org
mark.a...@comcast.net

Patrick R. Michaud

unread,
May 4, 2005, 11:44:11 AM5/4/05
to Mark A. Biggar, trewth...@yahoo.com, perl6-c...@perl.org
On Wed, May 04, 2005 at 07:29:35AM -0700, Mark A. Biggar wrote:
> 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.

Be careful here, although C<xor> is indeed a binary op, that doesn't
make it a boolean one. In particular, C<xor> is NOT associative:

print ( ("a" xor "b") xor "c"); # outputs "c"

print ( "a" xor ("b" xor "c")); # outputs "a"

We might get the "select one value" interpretation of C<xor>
if xor is defined as a chained operator of some sort, but that's
really up to the perl6-language folks to decide (and any folloups
on that topic should go there).

Pm

Mark A Biggar

unread,
May 6, 2005, 4:52:17 PM5/6/05
to Trewth Seeker, Mark A. Biggar, perl6-c...@perl.org
Well, consider expressions with xor that only contain values 1 and 0.
What should "1 xor 1 xor 1" return? Least surprise would suggest
that it should be 1 not 0. I was ignoring the fact that non-zero values perk through (which is not very useful in the "xor" case, unlike that for "or" or
"and") and only was considering the eventual boolean meaning of the result.

Yes, we are discussing the definition of the language and of course there isn't
any such function as xor(p1,p2,p3...) yet. We are attempting to determine just what that should mean it it were to be added. All we really have to go
on right now is the carry over of the meaning from perl5 of "p1 xor p2 xor p3" which happens to be the same as "p1 xor (p2 xor p3))", I.e., built from a binary right-associative "xor" op.

--
Mark Biggar
ma...@biggar.org
mark.a...@comcast.net
mbi...@paypal.com

> > 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.

Trewth Seeker

unread,
May 6, 2005, 4:15:37 PM5/6/05
to Mark A. Biggar, perl6-c...@perl.org

-- ts



Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

Reply all
Reply to author
Forward
0 new messages