From: larry Author: larry
Date: Thu Jul 17 11:05:58 2008
New Revision: 14568

Modified:
doc/trunk/design/syn/S09.pod

Log:
typo from DietCoke++


Modified: doc/trunk/design/syn/S09.pod
==============================================================================
--- doc/trunk/design/syn/S09.pod (original)
+++ doc/trunk/design/syn/S09.pod Thu Jul 17 11:05:58 2008
@@ -789,7 +789,7 @@
@x[0;1;42]
@x[0..10; 1,0; 1..*:by(2)]

-Built-in array types are expected succeed either way, even if
+Built-in array types are expected to succeed either way, even if
the cascaded subscript form must be implemented inefficiently by
constructing temporary slice objects for later subscripts to use.
(User-defined types may choose not to support the cascaded form, but

From: larry Author: larry
Date: Thu Jul 17 10:57:24 2008
New Revision: 14567

Modified:
doc/trunk/design/syn/S09.pod

Log:
Equivalence of cascaded and semicolon subscript forms suggested by nick++


Modified: doc/trunk/design/syn/S09.pod
==============================================================================
--- doc/trunk/design/syn/S09.pod (original)
+++ doc/trunk/design/syn/S09.pod Thu Jul 17 10:57:24 2008
@@ -12,9 +12,9 @@

Maintainer: Larry Wall <larry@wall.org>
Date: 13 Sep 2004
- Last Modified: 27 May 2008
+ Last Modified: 17 July 2008
Number: 9
- Version: 27
+ Version: 28

=head1 Overview

@@ -776,6 +776,27 @@

@x[0;1;42]

+=head1 Cascaded subscripting of multidimensional arrays
+
+For all multidimensional array types, it is expected that cascaded subscripts:
+
+ @x[0][1][42]
+ @x[0..10][1,0][1..*:by(2)]
+
+will either fail or produce the same results as the equivalent
+semicolon subscripts:
+
+ @x[0;1;42]
+ @x[0..10; 1,0; 1..*:by(2)]
+
+Built-in array types are expected succeed either way, even if
+the cascaded subscript form must be implemented inefficiently by
+constructing temporary slice objects for later subscripts to use.
+(User-defined types may choose not to support the cascaded form, but
+if so, they should fail rather than providing different semantics.)
+As a consequence, for built-in types of declared shape, the appropriate
+number of cascaded subscripts may always be optimized into the
+semicolon form.

=head1 The semicolon operator

From: larry Author: larry
Date: Wed Jul 16 23:52:23 2008
New Revision: 14566

Modified:
doc/trunk/design/syn/S04.pod

Log:
suggestion from moritz++ that POST blocks be allowed to see the return value


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Jul 16 23:52:23 2008
@@ -14,7 +14,7 @@
Date: 19 Aug 2004
Last Modified: 16 July 2008
Number: 4
- Version: 67
+ Version: 68

This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -1060,6 +1060,14 @@
before C<BEGIN>, C<CHECK>, or C<INIT>, since those are done at compile or
process initialization time).

+For blocks such as C<KEEP> and C<POST> that are run when exiting a
+scope normally, the return value (if any) from that scope is available
+as the current topic. (It is presented as a C<Capture> object.)
+The topic of the outer block is still available as C<< OUTER::<$_> >>.
+Whether the return value is modifiable may be a policy of the block
+in question. In particular, the return value should not be modified
+within a C<POST> block, but a C<LEAVE> block could be more liberal.
+
=head1 Statement parsing

In this statement:

From: larry Author: larry
Date: Wed Jul 16 23:26:04 2008
New Revision: 14565

Modified:
doc/trunk/design/syn/S04.pod

Log:
clarification suggested by Bob Rogers++


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Jul 16 23:26:04 2008
@@ -1276,8 +1276,8 @@
symbol tables visible at compile time, this binds to the compile-time
view of the lexical scopes. (At run-time, the initial run-time view
of these scopes is copied from the compiler's view of them, so that
-initializations carry over, for instance.) At run time, whenever such
-a subroutine needs to be cloned, an additional C<:=> binding is done
+initializations carry over, for instance.) At run time, when such
+a subroutine is cloned, an additional C<:=> binding is done
at clone time to the same symbol table entry that the original C<::=>
was bound to. (The binding is not restored on exit from the current
lexical scope; this C<:=> binding records the I<last> cloning, not

From: larry Author: larry
Date: Wed Jul 16 15:53:34 2008
New Revision: 14564

Modified:
doc/trunk/design/syn/S04.pod

Log:
typo from Brandon++


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Jul 16 15:53:34 2008
@@ -1290,7 +1290,7 @@
do not need a compile-time C<::=> binding, but like global subs,
they perform a C<:=> binding to the lexical symbol at clone time
(again, conceptually at the entry to the outer lexical scope, but
-possible deferred.)
+possibly deferred.)

sub foo {
# conceptual cloning happens to both blocks below

From: Brandon S. Allbery KF8NH, larry Author: larry
Date: Wed Jul 16 12:56:34 2008
New Revision: 14563

Modified:
doc/trunk/design/syn/S04.pod

Log:
[S04] another whack at defining consistent closure semantics


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Jul 16 12:56:34 2008
@@ -12,9 +12,9 @@

Maintainer: Larry Wall <larry@wall.org>
Date: 19 Aug 2004
- Last Modified: 12 July 2008
+ Last Modified: 16 July 2008
Number: 4
- Version: 66
+ Version: 67

This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -1253,27 +1253,64 @@
is free to turn unreferenced closures into mere blocks of code.
It is also free to turn referenced closures into mere anonymous
subroutines if the block does not refer to any external lexicals that
-should themselves be cloned. In particular, named subroutines in any
-scope do not consider themselves closures unless you take a reference
-to them. So
+should themselves be cloned. (When we say "clone", we mean the way
+the system takes a snapshot of the routine's lexical scope and binds
+it to the current instance of the routine so that if you ever use
+the current reference to the routine, it gets the current snapshot
+of its world in terms of the lexical symbols that are visible to it.)
+
+All remaining blocks are conceptually cloned into closures as soon
+as the lexical scope containing them is entered. (This may be done
+lazily as long as consistent semantics are preserved, so a block
+that is never executed and never has a reference taken can avoid
+cloning altogether. Execution or reference taking forces cloning
+in this case--references are not allowed to be lazily cloned, since
+no guarantee can be made that the scope needed for cloning will
+remain in existence over the life of the reference.)
+
+In particular, named subroutines are a special problem when embedded in
+a changing lexical scope (when they make reference to it). The binding
+of such a definition to a name within a symbol table counts as taking
+a reference, so at compile time there is an initial C<::=> binding
+to the symbol table entry in question. For "global" bindings to
+symbol tables visible at compile time, this binds to the compile-time
+view of the lexical scopes. (At run-time, the initial run-time view
+of these scopes is copied from the compiler's view of them, so that
+initializations carry over, for instance.) At run time, whenever such
+a subroutine needs to be cloned, an additional C<:=> binding is done
+at clone time to the same symbol table entry that the original C<::=>
+was bound to. (The binding is not restored on exit from the current
+lexical scope; this C<:=> binding records the I<last> cloning, not
+the currently in-use cloning, so any use of the global reference must
+take into consideration that it is functioning only as a cache of the
+most recent cloning, not as a surrogate for the current lexical scope.)
+
+Lexical names do not share this problem, since the symbol goes out
+of scope synchronously with its usage. Unlike global subs, they
+do not need a compile-time C<::=> binding, but like global subs,
+they perform a C<:=> binding to the lexical symbol at clone time
+(again, conceptually at the entry to the outer lexical scope, but
+possible deferred.)

sub foo {
+ # conceptual cloning happens to both blocks below
my $x = 1;
- my sub bar { print $x } # not cloned yet
- my &baz = { bar(); print $x }; # cloned immediately
- my $code = &bar; # now bar is cloned
+ my sub bar { print $x } # already conceptualy cloned, but can be lazily deferred
+ my &baz := { bar(); print $x }; # block is cloned immediately, forcing cloning of bar
+ my $code = &bar; # this would also force bar to be cloned
return &baz;
}

-When we say "clone", we mean the way the system takes a snapshot of the
-routine's lexical scope and binds it to the current instance of the routine
-so that if you ever use the current reference to the routine, it gets
-the current snapshot of its world, lexically speaking. (When we say that
-named subroutines do not consider themselves closures, this is a bit of a
-fib, since we must, in fact, take a reference to the subroutine in order to
-store it into the symbol table! But this operation happens at compile time
-so the lexical scopes in view are just the initial prototype lexical scopes
-visible to the compiler.)
+In particular, blocks of inline control flow need not be cloned until
+called. [Note: this is currently a potential problem for user-defined
+constructs, since you have to take references to blocks to pass them
+to whatever is managing the control flow. Perhaps the laziness can
+be deferred through Captures to binding time, so a slurpy of block
+refs doesn't clone them all prematurely. On the other hand, this
+either means the Capture must be smart enough to keep track of the
+lexical scope it came from so that it can pass the info to the cloner,
+or it means that we need some special fat not-cloned-yet references
+that can carry the info lazily. Neither approach is pretty.]

Some closures produce C<Code> objects at compile time that cannot be
cloned, because they're not attached to any runtime code that can

From: François Perrad, Bernhard Schmalhofer Hi,

on behalf of the Parrot team, I'm proud to announce the release of
Parrot 0.6.4
"St. Vincent Amazon."

Parrot 0.6.4 is available via CPAN, or follow the download
instructions at http://parrotcode.org/source.html. For those who would
like to develop on
Parrot, or help develop Parrot itself, we recommend using Subversion on
the source code repository to get the latest and best Parrot code.

Parrot 0.6.4 News:
- Documentation
+ removed a lot of old information from the FAQ
+ improved function level documentation
- Configuration
+ removed the configuration item 'has_gnu_m4'
+ refactored ICU-detection
- Languages
+ ChitChat
- improved the Smalltalk implementation
+ Pipp
- renamed Plumhead to Pipp
- support for a lot of builtin functions.
- Pipp now uses PHP specific data types.
- converted from PCT with TGE to PCT with NQP actions
- improvements in the PCT variant by using optok parsing
- start of object support
+ pir
- simple assignments work
+ json
- added a PCT-based implementation of JSON parsing
+ lolcode
- improved handling of symbols
- added support for block handling
- added support for globals
+ Lua
- more tests
+ Rakudo
- updated Range implementation
- added enums
- added generic type declarations (::T)
- added runtime mixing of roles with 'does' and 'but'
- added generic type declarations
- fixed handling of implicit lexicals ($_, $!, and $/)
- fixed implicit method calls on $_
- improved complex math builtins, added Complex
- moved many builtins to class Any
- declaration of lists of variables now work
- improved test infrastructure
- 910 additional passing spec tests since last release
- more convergence with STD.pm grammar
- added named 0-ary parsing and ops
- Compilers
+ PCT:
- allowed subroutine and method names to be a PAST tree that
produces the name
- Improved lexical handling
- Tools
+ pbc_disassemble renamed from disassemble
- Implementation
+ allowed .macro_const in PIR
+ added the flag :lexid(...) for subroutines
+ made multiple dispatch work for sub types
+ fixed garbage collection bug related to the metadata attached to a
PMC_EXT structure
+ added a warning when using deprecated opcodes
+ simplified the stacks implementation
+ fixed C++ build
+ improved closure and lexical support
+ improved IMCC register allocator
+ added cache for all runtime-constant strings, reducing memory usage
- Miscellaneous
+ improved OpenGL/GLU/GLUT bindings
+ added a standard profile for Perl::Critic coding standard testing
+ added support for smoke testing with Smolder
+ enabled use of Test::Harness 3.0 if available, but don't require it
for 'make test'
+ added the executable 'parrot_config' to query Parrot configuration


Many thanks to all our contributors for making this possible, and our
sponsors
for supporting this project. Our next scheduled release is August 19th
2008.

Enjoy!

From: Jon Lang, Moritz Lenz, Larry Wall, mark.a.biggar Today bacek++ implement complex logarithms in rakudo, and one of the
tests failed because it assumed the result to be on a different complex
plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected).

Should we standardize on one complex plane (for example -pi <= $c.angle
< pi like Complex.angle does)? Or simply fix the test to be agnostic to
complex planes?

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From: Nicholas Clark, Adrian Kreher, Larry Wall Hi,

I'm reviewing the tests in S09, and the file
t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0]
indexing format interchangeably with [0;0].

These two formats mean two different things, correct? The [0][0] form isn't
mentioned much in the spec, nor is [0;0] or if they interact somehow.

Thanks,
--
Adrian Kreher

From: Jon Lang, Aristotle Pagaltzis, TSa , Dave Whipp HaloO,

I know that the hot phase of the operator discussions are over.
But here's a little orthogonalizing idea from my side. The observation
is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5
and ** as repeated multiplication. Now imagine having a meta_postfix:<*>
that gives +* as multiplication (perhaps abbreviated as *) and ** as
(integer) exponentiation. We can then continue with replication as ~*
for strings and ,* for lists thus freeing x and xx as some generic
multiplication operators.

The meta * also is useful e.g. as (1,2) Z* 3 === (1,1,1),(2,2,2). Also
when we apply it to unary postfix as well: $x++* 3 === $x++.++.++ which
is useful when $x is of some class with overloaded ++ where the single
steps are important. The meta postfix * could also be stacked and tetration
falls out naturally as ***.

With + as the default case for meta_postfix:<*> we win the advantage that
we have +* and * as multiplication operators with the latter being a special
form of the former. But for Vectors +* would automatically yield the scalar
multiplication infix:<+*>:(Vector,Num) when infix:<+>:(Vector,Vector) is
defined as expected.


Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan

From: Patrick R. Michaud What would be the expected output from the following?

my $a = foo();
my $b;

{
my $x = 1;
sub get_x() { return $x; }
sub foo() { return &get_x; }
$b = foo();
}

my $c = foo();

say "a: ", $a();
say "b: ", $b();
say "c: ", $c();

As a followup question, what about...?

my @array;
for 1..3 -> $x {
sub get_x() { return $x; }
push @array, &get_x;
}

for @array -> $f { say $f(); }

Pm

From: larry Author: larry
Date: Sat Jul 12 10:50:57 2008
New Revision: 14562

Modified:
doc/trunk/design/syn/S04.pod

Log:
[S04] small clarification to whether named subs are really closures


Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Sat Jul 12 10:50:57 2008
@@ -12,9 +12,9 @@

Maintainer: Larry Wall <larry@wall.org>
Date: 19 Aug 2004
- Last Modified: 2 Apr 2008
+ Last Modified: 12 July 2008
Number: 4
- Version: 65
+ Version: 66

This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -1268,7 +1268,12 @@
When we say "clone", we mean the way the system takes a snapshot of the
routine's lexical scope and binds it to the current instance of the routine
so that if you ever use the current reference to the routine, it gets
-the current snapshot of its world, lexically speaking.
+the current snapshot of its world, lexically speaking. (When we say that
+named subroutines do not consider themselves closures, this is a bit of a
+fib, since we must, in fact, take a reference to the subroutine in order to
+store it into the symbol table! But this operation happens at compile time
+so the lexical scopes in view are just the initial prototype lexical scopes
+visible to the compiler.)

Some closures produce C<Code> objects at compile time that cannot be
cloned, because they're not attached to any runtime code that can

From: Patrick R. Michaud, Larry Wall, TSa
t/spec/S29-list/sort.t has the following test:

my @a = (2, 45, 6, 1, 3);
my @e = (1, 2, 3, 6, 45);
my @s = { $^a <=> $^b }.sort: @a;
is(@s, @e, '... with closure as direct invocant');

S29 doesn't show a 'sort' method defined on block/closure
invocants... should there be?

Note that we already have:

my @s = sort { $^a <=> $^b }, @a;
my @s = @a.sort { $^a <=> $^b };

A similar question applies for .reduce in S29-list/reduce.t :

is(({ $^a * $^b }.reduce: 1,2,3,4,5), 120, "basic reduce works (3)");

Thanks!

Pm

From: larry Author: larry
Date: Thu Jul 10 19:03:34 2008
New Revision: 14561

Modified:
doc/trunk/design/syn/S12.pod

Log:
[S12] s/bool/Bool/


Modified: doc/trunk/design/syn/S12.pod
==============================================================================
--- doc/trunk/design/syn/S12.pod (original)
+++ doc/trunk/design/syn/S12.pod Thu Jul 10 19:03:34 2008
@@ -14,7 +14,7 @@
Date: 27 Oct 2004
Last Modified: 10 Jul 2008
Number: 12
- Version: 60
+ Version: 61

=head1 Overview

@@ -1352,7 +1352,7 @@

is short for something like:

- 0 but bool::True
+ 0 but Bool::True

A property is defined by a role like this:

@@ -1707,7 +1707,7 @@
or the old one.) Any explicit sub or type definition hides all imported
enum values of the same name but will produce a warning unless
C<is redefined> is included. Note that true() is a built-in function,
-while True is short for C<bool::True>.
+while True is short for C<Bool::True>.

Enum values may be used as a property on the right side
of a C<but>, and the enum type will be intuited from the value to make
@@ -1764,13 +1764,15 @@

Two built-in enums are:

- our bit enum *bool <False True>;
- our bit enum *taint <Untainted Tainted>;
+ our bit enum Bool <False True>;
+ our bit enum Taint <Untainted Tainted>;

-Note that C<bool> and C<taint> are really role names. You can call
-C<.bool> on any built-in type, but the value returned is of type C<bit>.
-Never compare a value to "C<true>", or even "C<True>". Just use it
-in a boolean context.
+Note that C<Bool> and C<Taint> are really role names, and the enum
+values are really subset types of the C<bit> integer type. You can
+call the C<.Bool> coercion or the C<true> function or the C<?>
+prefix operator on any built-in type, but the value returned is of
+type C<bit>. Never compare a value to "C<true>", or even "C<True>".
+Just use it in a boolean context.

=head1 Open vs Closed Classes

From: Conrad Schneiker, Moritz Lenz, Bob Rogers > Moritz Lenz wrote (on perl6-compiler)
> Patrick R. Michaud wrote:
> >> +S02-builtin_data_types/num.t
> >> S02-builtin_data_types/type.t
> >> S02-literals/autoref.t
> >> S02-literals/hex_chars.t # pure
> >> S02-literals/radix.t
> >> S02-polymorphic_types/subset-code.t # pure
> >> S02-polymorphic_types/subset-range.t
> >> +S03-operators/assign-is-not-binding.t
> >> S03-operators/autoincrement.t # pure
> >> S03-operators/comparison.t
> >> S03-operators/context.t
> >
> > In the test suite, could we perhaps aim for some
> > consistency on the use of hyphens versus underscores,
> > or at least articulate when one is used versus the other?
> > For example, "assign-is-not-binding.t" versus "hex_chars.t"
> > in the above.
> >
> > Personally I vastly prefer hyphens to underscores,
>
> Same here. Since the directly names already match m/^S\d\d-/ I'll
> assume
> that will be our standard.
>
> > but I
> > suspect people have good reasons for preferring underscores.

One reason (probably not a good one) is to use the same
convention as programming language variable names (which is
typically more of a "CamelCase" versus "not_Camel_case" issue).

Likewise, I suspect some people would also prefer hyphens to
either {underscores or CamelCase} in variable names as well (as
in Lisp).

So would a user-supplied Perl 6 syntax-morphing module to allow
use of embedded-hyphens in variable names (and other names, such
as labels and subs) to Perl 6 (with minimally-sane adjustments
needed to make hyphen-related operator parsing unambiguous) be
reasonably feasible? Or does this open a messy Pandora's box of
cascading language-redesign kludges?

(I suspect similar issues came up in language design discussions,
but my initial searches didn't turn up anything directly
relevant.)

Best regards,
Conrad Schneiker

www.AthenaLab.com

Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Official Parrot Wiki - http://www.perlfoundation.org/parrot

From: Patrick R. Michaud, Ovid, Trey Harris, Moritz Lenz Do C<grep> and C<reverse> act like the C<join> method, in that
they work for C<Any> object and not just objects of type C<List>?

In other words,, should C< $x.grep(...) > work even if
$x isn't normally a list type?

Pm

From: Moritz Lenz, Mark J. Reed, Larry Wall, Aristotle Pagaltzis Most financial institutions don't use float, rational or fixed point, they just keep integer pennies.

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

-------------- Original message ----------------------
From: Larry Wall <larry@wall.org>

> Would any financial institution care to comment?
>
> Larry

From: Moritz Lenz, Daniel Ruoso, Larry Wall In the test suite there are some tests like this:
is(1.WHAT, 'Int', '1 as a literal is an Int);

This seems to imply that we guarantee the direct type of literals. But
do we?

Actually I see no need for that. All my programs work fine if the
literal 1 is of type Foo, and Foo isa Int.

What's our policy on that? Will a 1.WHAT always return Int? do we
guarantee (1..4).WHAT always to be 'Range'?

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From: Moritz Lenz Another question:

Vasily Chekalkin (via RT) wrote:
> +.sub 'sqrt' :multi(Complex)
> + .param pmc a
> + a = sqrt a
> + .return (a)
> +.end

Do we actually want a sqrt(Complex)? Somebody who is sufficiently
mathematically educated to work with complex numbers should now that
sqrt() is ambigous, because there are two possible results, and will
revert to roots() for that.

Any thoughts?

Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From: Patrick R. Michaud, Moritz Lenz Following up to a thread on p6c regarding method fallbacks and .join:

* What should [1,3,5].join('-') produce?

* How about ([1,3,5], 20).join('-') ?

Thanks!

Pm

From: Ovid, Jon Lang Hi all,

I use Perl6::Junction in Perl 5 and recently the author implemented the
"values" method on junctions. I needed this because I sometimes find
that I need to do something conceptually similar to this:

my $number = any( 0 .. 19 );
while ($number->values) {
my $rand int(rand(20));
if ( $number == $random_number ) {

# handle some task and discard the number
$number = any( grep { $_ != $rand } $number->values );
}
}

In other words, sometimes I have code which receives a junction and
needs to provide a new junction based on the values of the old
junction, but with some values removed.

How do I do that in Perl 6? I can't see that in the docs. Clearly we
don't this to be done destructively as I suspect this will break
autothreading, but building new junctions based on old junctions seems
reasonable.

Cheers,
Ovid

--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Official Parrot Wiki - http://www.perlfoundation.org/parrot

From: Adrian Kreher Hello,

I'm Adrian, the Summer of Code student who is working on the test suite hosted
in the Pugs repo. You might have seen me on IRC as Auzon.

A while back, I started a file (pugs/t/TASKS) in the repository to hold a list
of things that need to be done on the test suite. I want to make it easier
for implementers to communicate with the contributors for the test suite on
what is lacking in the test suite. This allows test writers to see what would
be the most beneficial to implementers, and also make it easier for new
contributors to join in with a task in mind.

So, if you see any tests that seem wrong, any areas that are undertested or
even untested, please add them to pugs/t/TASKS with the relevant synopsis.

Thanks,
--
Adrian Kreher

From: Alberto Simões, Nuno 'smash' Carvalho Greetings,

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.3
"Beautiful Parrot." Parrot (http://parrotcode.org/) is a virtual machine aimed
at running all dynamic languages.

Parrot 0.6.3 is available via CPAN (soon), or follow the download
instructions at http://parrotcode.org/source.html. For those who
would like to develop on
Parrot, or help develop Parrot itself, we recommend using Subversion on
the source code repository to get the latest and best Parrot code.

Parrot 0.6.3 News:
- Specification
+ updated pdd09_gc.pod
- Languages
+ Cardinal:
- dramatically improved parsing speed
- added support for defining and instantiating classes
- started fleshing out the builtin class hierarchy
- added support for hashes and arrays
+ Chitchat: added the start of a smalltalk compiler
+ Pheme: updated to match PGE changes
+ Pynie: return statement, other minor updates
+ Rakudo:
- added working list and hash contexts
- added 'return' statements
- added => pair constructor
- added ?? !! ternary
- added Range, range operators, Complex
- added common List, Hash methods
- refactored base classes
- added Mutable, Perl6Scalar classes
- added type-checking, is readonly/rw/copy for parameters
- added make localtest, docs/spectest-progress.csv
- fix named unaries
+ Squaak: implement return statement
+ Tcl: updated control flow exceptions to use new builtin types
- Compilers
+ All tools converted to P6object metamodel
+ PGE:
- <?foo> is now a zero-width match
- reduced backtracking to improve parsing speed
+ PCT:
- added "return" PAST.op node type for subroutine returns
- added "keyed_int" scoping to PAST::Var
- fixed calls to closures
- automatically transcode 7-bit unicode to ascii for faster processing
+ NQP: added "return" statement, ?? !! ternary operator
- Configuration
+ expanded step gen::opengl
- Implementation
+ updated function and macro names to match pdd09_gc.pod
+ removed Super PMC
+ add ".namespace []" as alternative to ".namespace"
+ "make codetest" target runs standard coding tests
- Miscellaneous
+ added P6object class for Perl 6 interfaces to objects in Parrot
+ ported OpenGL/GLU/GLUT bindings to Win32, BSD, and more Mac OS X variants
+ generate OpenGL/GLU/GLUT bindings by parsing system headers
+ new OpenGL example shapes.pir, covering basic OpenGL 1.1 / GLUT 3 APIs
+ new float4.pir structure-packing benchmark
+ reduced memory use for variables
+ improved constant string caching
+ made code g++ and gcc (with optimizations) safe
+ the usual collection of bugfixes and optimizations


Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 15 July 2008.

Enjoy!
./smash

From: larry Author: larry
Date: Sat Jun 14 17:06:09 2008
New Revision: 14552

Modified:
doc/trunk/design/syn/S05.pod

Log:
this sentence no verb, diakopter++


Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Sat Jun 14 17:06:09 2008
@@ -346,7 +346,7 @@

The primary intent of these rules is to minimize format disruption
when substitution happens across line boundaries and such. There is,
-of course, no guarantee that the result will exactly what a human would
+of course, no guarantee that the result will be exactly what a human would
do.

The C<:s> modifier is considered sufficiently important that

From: TSa , Moritz Lenz, Daniel Ruoso, Larry Wall In the test suite and on IRC there was quite some confusion about how
list builtins are specced, and how they should behave in corner cases.

One is join():
our Str multi method join ( @values: Str $separator = ' ' )
our Str multi join ( Str $separator = ' ', *@values )

It is quite clear that the perl 5-style
join 'sep', $value, $value2;
invocation remains valid, and
@list.join($sep)
is the new method form.

The confusion arises what to do with
'str'.join('other_str')
should be.

Fallback semantics in S12 suggest that since no matching multi method is
found, subs are tried - that is, the expression is interpreted as
join('str', 'other_str')
yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
result to be 'str'.

Daniel Ruoso argued in favour of the tested behaviour, suggesting that
perhaps the specs should be updated accordingly, mostly because
('str').join('other_str')
would be confusing otherwise.

Patrick Michaud argued in favour of the specced behaviour, and I agree.
Mostly because nobody sane will write things like
'str'.join('other_str') with a literal string as the invocant in first
place. And if it's not a literal, and you want it to behave as list, the
invocant is either something that returns a list, or a variable with the
'@' sigil. We just need to be careful that everything that should return
really does that, even if it contains a single list.

Currently both pugs and rakudo make <a b> return a list (pugs actually
an array, but that's a different problem), but <a> is a Str.
If we'd just be more consistent and always return a list, I don't see a
problem with the spec. If not, it would be rather weird to have <a
b>.join('c') return 'abc', but <a>.join('c') return 'c'.

Consider
my $x = A.new();
$x.y = <a>;
say $x.y.join('b')
The output is different for the two possible declarations of class A:
class A { has $y is rw } # -> b
class A { has @y is rw } # -> a
not pretty IMHO.

So I see the following options:
1) be more consistent with what returns a list
2) Add a method with invocant Any for each list builtin
3) drop method fallback, thus disallowing Str.join(Str) outright
4) be lisp, make everything a list *g* (not serious)

I haven't thought a lot about the third option, and what it would mean
to the language as a whole, so I have no idea if it's a viable alternative.

Any thoughts on the topic are welcome. I hope I didn't confuse too much
here ;-)

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From: larry Author: larry
Date: Wed Jun 11 17:53:27 2008
New Revision: 14551

Modified:
doc/trunk/design/syn/S05.pod

Log:
added <...> et al. as suggested by ruoso++


Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Wed Jun 11 17:53:27 2008
@@ -16,7 +16,7 @@
Date: 24 Jun 2002
Last Modified: 11 Jun 2008
Number: 5
- Version: 80
+ Version: 81

This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I<regex> rather than "regular
@@ -1410,6 +1410,15 @@

=item *

+The C<< <...> >>, C<< <???> >>, and C<< <!!!> >> special tokens
+have the same "not-defined-yet" meanings within regexes that the bare
+elipses have in ordinary code. (However, by the recursive rules above,
+C<< <!!> >> is equivalent to C<< <?> >>, which matches the null string.
+Likewise C<< <!!before x> >> is just like C<< <?before x> >>, except
+that it is ignored by the longest-token matcher.)
+
+=item *
+
A leading C<*> indicates that the following pattern allows a
partial match. It always succeeds after matching as many characters
as possible. (It is not zero-width unless 0 characters match.)

From: larry Author: larry
Date: Wed Jun 11 17:34:50 2008
New Revision: 14550

Modified:
doc/trunk/design/syn/S05.pod

Log:
fixed "samebase" illogic pointed out by moritz++


Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Wed Jun 11 17:34:50 2008
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <pmichaud@pobox.com> and
Larry Wall <larry@wall.org>
Date: 24 Jun 2002
- Last Modified: 18 May 2008
+ Last Modified: 11 Jun 2008
Number: 5
- Version: 79
+ Version: 80

This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I<regex> rather than "regular
@@ -181,7 +181,7 @@
The single-character modifiers also have longer versions:

:i :ignorecase
- :b :basechar
+ :a :ignoreaccent
:g :global

=item *
@@ -227,7 +227,7 @@

=item *

-The C<:b> (or C<:basechar>) modifier scopes exactly like C<:ignorecase>
+The C<:a> (or C<:ignoreaccent>) modifier scopes exactly like C<:ignorecase>
except that it ignores accents instead of case. It is equivalent
to taking each grapheme (in both target and pattern), converting
both to NFD (maximally decomposed) and then comparing the two base
@@ -237,7 +237,7 @@
includes all ignored characters, including any that follow the final
base character.

-The C<:bb> (or C<:samebase>) variant may be used on a substitution to change the
+The C<:aa> (or C<:sameaccent>) variant may be used on a substitution to change the
substituted string to the same accent pattern as the matched string.
Accent info is carried across on a character by character basis. If
the right string is longer than the left one, the remaining characters
@@ -968,8 +968,8 @@
unless it happens to be a C<Regex> object, in which case it is matched
as a subrule. As with scalar subrules, a tainted subrule always fails.
All string values pay attention to the current C<:ignorecase>
-and C<:basechar> settings, while C<Regex> values use their own
-C<:ignorecase> and C<:basechar> settings.
+and C<:ignoreaccent> settings, while C<Regex> values use their own
+C<:ignorecase> and C<:ignoreaccent> settings.

When you get tired of writing:

@@ -1069,7 +1069,7 @@
=back

All hash keys, and values that are strings, pay attention to the
-C<:ignorecase> and C<:basechar> settings. (Subrules maintain their
+C<:ignorecase> and C<:ignoreaccent> settings. (Subrules maintain their
own case settings.)

You may combine multiple hashes under the same longest-token

From: Mark J. Reed, TSa, jerry gay, Ruud H.G. van Tol Author: larry
Date: Wed Jun 11 16:49:17 2008
New Revision: 14549

Modified:
doc/trunk/design/syn/S03.pod

Log:
Fixes suggested by Ryan++


Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Wed Jun 11 16:49:17 2008
@@ -1057,8 +1057,11 @@

Note that these differ:

- $min ..^ $max $ min .. $max-1
- $min .. ^$max # $min .. (0..$max-1)
+ 0 ..^ 10 # 0 .. 9
+ 0 .. ^10 # 0 .. (0..9)
+
+(It's not yet clear what the second one should mean, but whether it
+succeeds or fails, it won't do what you want.)

=back