2 views

Skip to first unread message

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:

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

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

-???

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.

> 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

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

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

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

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

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

>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

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?

> 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

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?

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

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.

> 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

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

> 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

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.

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.

> 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

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.

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

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):

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

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.

> 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

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.

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

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.

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.

> 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

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.

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.

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

Search

Clear search

Close search

Google apps

Main menu