Re: YAPC::EU and Perl 6 Roles

[Raphael Descamps]

Am Freitag, den 10.07.2009, 17:06 -0700 schrieb Jon Lang:
> How about this: in role composition, "mandate" causes methods to take
> precedence over other methods with which they would normally conflict,
> and to conflict with methods that would normally take precedence over
> them.

I really dislike this because it is contrary to the original idea of the
"stateless traits" as defined in the original paper from Nathanael
Schärli.
The main reason why "traits" have been introduced was to solve the
problems inherent to mixins. In mixins the main problem is that the
class using the mixin is not able to control the composition (which is
simply done sequencially) and that lend to fragile hierarchies.

The brilliant idea with "traits" is that it bring back the control to
the class consuming the "trait" and conflicts have to be solved
explicitly. The traits paper propose 3 different operators to solve such
conflicts: overriding, excluding or aliasing.

I definitively think that perl 6 roles should also have an excluding
operator because I think that *every* composition conflicts arrising
should be solvable by the class comsuming the role.

What you propose here is a step behind: you reintroduce the problem
existing with mixins by bringing back precedence rules in the way
composition is made.

So far, I have only seen reference to the original paper decribing the
"stateless traits". As roles are an implementation of "stateful traits",
maybe we should start to point to the paper formalising it:
http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf

>   So:
> 
> role R1 { mandate method foo { ... } }
> role R2 { method foo { ... } }
> class C does R1 does R2 { ... }
> 
> Normally, the compiler would complain of a conflict between R1 and R2;
> but because R1::foo is mandated, it wins out.
> 
> role R { mandate method foo { ... } }
> class C does R { method foo { ... } }
> 
> Normally, C::foo would take precedence over R::foo; but because R::foo
> is mandated, the compiler complains of a conflict between C and R.
> 
> When two methods have the "mandate" keyword, they are compared to each
> other as if neither had the keyword.
> 
> role R { mandate method foo { ... } }
> class C does R { mandate method foo { ... } }
> 
> Since both R::foo and C::foo are mandated, C::foo supersedes R::foo.
> 
> Applying the "mandate" keyword to a role is shorthand for applying it
> to all of its methods.
> 
> mandate role R {
> method foo { ... }
> method bar { ... }
> method baz { ... }
> }
> 
> is the same as:
> 
> role R {
> mandate method foo { ... }
> mandate method bar { ... }
> mandate method baz { ... }
> }
> 
> This behavior can be overridden by the "suggest" keyword:
> 
> mandate role R {
> suggest method foo { ... }
> method bar { ... }
> method baz { ... }
> }
> 
> is the same as:
> 
> role R {
> method foo { ... }
> mandate method bar { ... }
> mandate method baz { ... }
> }
> 
> That is, every method is either mandated or suggested, and suggested
> by default.  Mandating a role changes the default for its methods, or
> you could explicitly suggest the role.  The latter possibility would
> allow for a pragma that changes the role's default importance from
> suggested to mandated.
> 
> Ovid's distinction between interface and unit of behavior could be
> managed by this distinction: "suggest role R" is primarily intended as
> an interface, with behavior being a suggestion only and implicitly
> overriden by the class; "mandate role R" is primarily intended as a
> unit of behavior, and overriding its behavior requires that you
> explicitly supersede it.  In Ovid's programs, he might start by saying
> "use mandate", so that roles operate as units of behavior by default,
> and can be declared as interfaces by saying "suggest role" instead of
> "role".  Or maybe the pragma declares "interface" as a synonym for
> "suggest role".  (I'd be more comfortable with this if I could think
> of a comparable synonym for "mandate role"; at that point, you could
> do away with the pragma - use "role", "suggest role", or "interface"
> to mean "interface", and use "mandate role" or ??? to mean "unit of
> behavior".)
> 
> At this point, you can strengthen the importance of a method (raising
> it from a suggestion to a mandate); but you cannot weaken it.  Thus,
> interfaces can be composed into units of behavior; but not vice versa:
> attempting to do so would result in a unit of behavior.  I think that
> the converse _should_ be possible; but I'm not quite sure how it might
> be done.
> 

xml grammar

[Raphael Descamps]

Hi,

I have seen that wayland76 was playing with an XML Grammar on #perl6, so
I think that it was maybe the time to send what I already have done.

Maybe it should be a perl6.user posting, but as there is actualy no
working xml library available for perl 6 and it is a good test for how
it feel to write a grammar with the actual specification, I post it
here. 

I simply started with the pseudo XML grammar from Moritz on his blog and
found myself reading the whole XML specification. I am definitively not
a XML specialist and have no experience with sax or libxml and simply
wanted to learn more about the perl 6 grammar syntax and features to be
able to anderstand STD.pm.

It's only a grammar for now without actions because a ran out of tuits.
It is using only tokens and no rules because at the time the overriding
of  was not working properly.

But hey, it (mostly) works and is a good examle of what you can do today
with a perl 6 :)

Feel free to propose better way to do it :)


xml.pl
Description: Perl program


Grammar.pm
Description: Perl program

Re: xml grammar

[Raphael Descamps]

Am Montag, den 03.08.2009, 11:04 +1000 schrieb Timothy S. Nelson:
> On Fri, 31 Jul 2009, Raphael Descamps wrote:
> 
> > Hi,
> >
> > I have seen that wayland76 was playing with an XML Grammar on #perl6, so
> > I think that it was maybe the time to send what I already have done.
> 
>   Raphael: I don't say any of this to discourage you,

Don't worry, you don't :)
I'm happy to see that there is already different implementations
available. In fact it's not surprising because the most blokers bugs and
missing features of PGE have been solved.

> but to present 
> alternatives to the list.

I knew that Francois was working on it, but last time that I checked it,
nothing was released. 

> http://github.com/krunen/xml/tree/master

> http://github.com/wayland/Tree/tree/master

> http://gist.github.com/161467

> Another version is at http://github.com/fperrad/xml/

So thanks for the pointers, I will have a look at the different
implementations.

Raphael

Perl 6 modules and classboxes?

[Raphael Descamps]

Hi,

In the last few months, I tried to anderstand better Roles aka statefull
traits, so I read differents traits papers about it. From the same
research group, I also read about classboxes and found the concept
interresting, particulary when combined with traits (roles).

Please note that I am not a computer science guy, so I anderstand more
or less the concepts but not the mathematical formal description. 

I tried to read the Synopse S11 and how modules will be working in Perl
6: to be honest I still not really anderstand it :)

As Perl 6 will be supporting multiple versions installed of the same
module and also support import with lexical scoping, I was asking myself
if it was possible to combine some of the interresting properties of
classboxes like local rebinding, flattening property and the idea that
import takes precedence over inheritance.

I am absolutly not sure if it fit to the Perl 6 module concept as a
whole, but I will be happy to read your comments and what you think
about it.

A few pointers:

classboxes+traits introduction:
http://scg.unibe.ch/archive/papers/Berg05dTraitsClassbox.pdf

For an in depth description, you can also read the Ph.D. thesis:
http://scg.unibe.ch/archive/phd/bergel-phd.pdf

To develop the classbox concept, the autors also introduced a module
calculus, which also help to describe the difference existing beetween
different modules systems: (such a module calculus can also help to
better anderstand the interaction beetween different languages): 
http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf

I will be on Holiday for the next 3 weeks and will probably be offline
most of the time, so don't take a no reply for indifference. I know that
it's not a good idea to propose something like that and disappear
immediatly, but a saw that S11 was on a heavily rework phase and that it
is now or never to open my mouth :)

Raphael.

Re: Perl 6 modules and classboxes?

[Raphael Descamps]

> I tried to read the Synopse S11 and how modules will be working in Perl
> 6: to be honest I still not really anderstand it :)

What may help me is to know where Perl 6 modules are to be placed in the
module taxonomy used in the module calculus paper below.

> To develop the classbox concept, the autors also introduced a module
> calculus, which also help to describe the difference existing beetween
> different modules systems: (such a module calculus can also help to
> better anderstand the interaction beetween different languages): 
> http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf

Raphael.

Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk

[Raphael Descamps]

A few other interesting metrics could be for example:

* Work done on the Specification (Synopses):
svn log docs/Perl6/Spec/

* TimToady hacking ;)
svn log src/perl6/
svn log src/perl6/STD.pm

* Work done on the Official Testsuite:
svn log t/spec/

* Work done on the Testsuite:
svn log t/
(It's interresting to compare it with the developement of the
specification as the correlation are obvious and it also show the Pugs
contribution)

Please note that the parrot commit curve seems to have slow down a
little lately...

It's because the parrot HLL languages have left the nest :)

> page 80 - graph of parrot commits and releases
> I don't have a url for that graph. Do you?
> Is it maintained? Can anyone update it for me?

In the Pugs Repository there is the 4 years old util/svnlog2graph.pl,
but beware because it is buggy and not delivering correct results:
(the dayify function and developers counting are both buggy...)

On the old wiki there is a somewhat newer Version of this file as
attachment but it has the same bugs:
http://www.perlfoundation.org/parrot/index.cgi?search_term=svnlog2graph.pl&action=search

An other old file delivering some statistik is parrot_dev_stat.pl:
http://www.perlfoundation.org/parrot/index.cgi?search_term=parrot_dev_stat.pl&action=search

(The parrot repository have moved but otherwise it seems to works, I
don't know if the results delivered are accurate)

Here a proposed fix for the version of svnlog2graph.pl found in the pugs
repository:
Index: util/svnlog2graph.pl
===
--- util/svnlog2graph.pl(Revision 28206)
+++ util/svnlog2graph.pl(Arbeitskopie)
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 # Creates a statistic of Pugs' development.
-# Usage: svn log | util/svnlog2graph.pl > /tmp/graph.png   --or
-#svn log > /tmp/log; util/svnlog2graph /tmp/log
> /tmp/graph.png
+# Usage: LANG=C svn log | util/svnlog2graph.pl > /tmp/graph.png   --or
+#LANG=C svn log > /tmp/log; util/svnlog2graph /tmp/log
> /tmp/graph.png
 
 use warnings;
 use strict;
@@ -23,10 +23,12 @@
 INFO
 
 # Read the logfile
-while(<>) {
+my @lines = reverse <>;
+foreach my $line (@lines) {
+#while(<>) {
   # Only process headlines
-  next unless m/^r/ and m/lines?$/ and m/\|/;
-  my ($dev, $date) = (split / \| /)[1, 2];
+  next unless $line =~ m/^r/ and $line =~ m/lines?$/ and $line =~
m/\|/;
+  my ($dev, $date) = (split / \| /, $line)[1, 2];
   $date =~ s/ [+-]\d+ \(.*$//;
 
   # Example: $date is now "2005-02-06 17:52:06"
@@ -36,10 +38,6 @@
   $num_commits++;
 }
 
-# $commits[0] should be first commit, not last
-...@commits= reverse @commits;
-...@developers = reverse @developers;
-
 # Collect commits in days
 # E.g. $commits_till_day[42] = 1500 (1500 commits from day 1 to day 42)
 my @commits_till_day = dayify(@commits);
@@ -52,17 +50,22 @@
 # Create the graph.
 my $graph = GD::Graph::lines->new(500, 350);
 $graph->set(
-  title=> "Pugs development",
+  title=> "Perl 6 development",
   x_label  => "Days",
-  y_label  => "Commits/Developers",
-  x_label_skip => 10,
-  y_max_value  => (int(@commits / 500) + 1) * 500,
+  two_axes => 1,
+  use_axis => [1,2],
+  y1_label  => "Commits",
+  y2_label  => "Developers",
+  x_label_skip => 365,
+  logo => "misc/camelia.jpg",
+  logo_resize => 0.1,
+  logo_position => "UL",
 ) or die $graph->error;
 
 my @data = (
   [ 0...@commits_till_day ],  # Day#
   [ 0, @commits_till_day ],  # Commits
-  [ 0, map { 50 * $_ } @devs_till_day ], # Developers (scaled)
+  [ 0, @devs_till_day ], # Developers
 );
 
 my $gd = $graph->plot(\...@data) or die $graph->error;
@@ -80,9 +83,8 @@
 if($cur_day != $#till_day) {
   push @till_day, $till_day[-1] || 0
 while $#till_day < $cur_day;
-} else {
-  $till_day[-1]++;
 }
+$till_day[-1]++;
   }
 
   return @till_day;

Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk

[Raphael Descamps]

Am Dienstag, den 15.09.2009, 16:46 +0200 schrieb Carl Mäsak:
> Tim (>), Carl (>>), Tim (>>>):
> >> > I'd be grateful for feedback on any of the slides, but I'm especially
> >> > interested in updates for:
> >> >
> >> >page 73 - Perl 6 implementations
> >> >I've added Mildew, with links, to the SMOP line
> >> >anything I should add / change / remove?
> >> >What's the status of KindaPerl6?
> >>
> >> I think Elf could very well be added to those.
> >>
> >> >page 77 - quantity of code writen in Perl 6
> >> >are there any other significant perl6 codebases?
> >>
> >> Again, Elf is a nice, large example. :)
> >
> > Got a url? (I've not been keeping up with perl6 as much as I'd like)
> 
> This one here seems a good introduction: .
> 
> >> Depending on what you mean by significant, I'd also like to direct
> >> your attention towards SVG::Plot, proto, Gamebase, CSV, Druid, Form,
> >> HTTP::Daemon, Perl6::SQLite and Web.pm. All of those can be downloaded
> >> via proto.
> >
> > I'd really appreciate a list of "significant" perl6 projects, with a
> > few words of description of each, that I could put on a slide.
> > (Similar to the "Many gems on CPAN ..." on page 18.)
> >
> > The goal being to give a sense that there are "significant" projects
> > being implemented in perl6.
> 
> The list I gave above was my subjective, somewhat hasty traversal of
> projects.list, filtering on what I consider significant (meaning that
> people use it today or it holds some promise). Here's the same list,
> with a one-sentence (also subjective) description of each project:

Some XML related stuff:

XML parser:
http://github.com/fperrad/xml/

Tree manipulation:
http://github.com/wayland/Tree/tree/master


> SVG::Plot
>   Draw bar charts, line charts and pie charts in SVG.
> proto
>   Install Perl 6 projects, painlessly.
> Gamebase
>   Create games with animated 2D sprites.
> CSV
>   Read .csv files.
> Druid
>   Play a connection game which grows upwards.
> Form
>   Format text nicely à la Exigesis 7.
> HTTP::Daemon
>   Make a web server.
> Perl6::SQLite
>   Interact with an SQLite database.
> Web.pm
>   Create web applications with powerful tools.
> 
> It's entirely possible that I've forgotten some important module
> above, so don't hesitate to pipe up if one comes to mind.
> 
> // Carl

Raphael.

Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk

[Raphael Descamps]

Am Mittwoch, den 16.09.2009, 10:30 +0200 schrieb François Perrad:
> 2009/9/16 Carl Mäsak :
> > Tim (>), Raphael (>>):
> >>> Some XML related stuff:
> >>>
> >>> XML parser:
> >>> http://github.com/fperrad/xml/
> No Perl6.
> Only Parrot & PCT.

Yes, I know.

But your XML grammar is Perl 6 syntax anyway ;)

If you want pure Perl6, here is an other small example:
http://github.com/krunen/xml

But as it stand now, it's more a stub.

It show that PGE is now mature enouth to start hacking on an XML Grammar
close to the W3C Spec.

Raphael.

> 
> François Perrad
> 
> >>>
> >>> Tree manipulation:
> >>> http://github.com/wayland/Tree/tree/master
> >>
> >> Thanks. Any reason they're not known to proto?
> >
> > The latter I wasn't really aware of. It's now added to the list, and
> > wayland has been given a proto commit bit.
> >
> > The former, while apparently a nice effort, doesn't contain any Perl 6
> > code as far as I can see.
> >
> > // Carl
> >
> >

Re: Cobra & Ioke Programming Languages

[Raphael Descamps]

> Also any thoughts on implementing Perl 6 on LLVM?

Well, the planning is already under way...

Parrot want to eventually use LLVM as one of the possible backend:
http://wknight8111.blogspot.com/2009/09/first-steps-on-jit-overhaul.html

At the moment, it is targeted for the 2.6 release:
https://trac.parrot.org/parrot/report/14

Bye, Raphael.

Re: Aliasing methods in CPAN roles

[Raphael Descamps]

Am Freitag, den 16.10.2009, 10:54 +0400 schrieb Richard Hainsworth:
> Arising out of "Freezing Roles" is a related question.
> 
> Suppose I download a module from CPAN with a role I want to use, but it 
> introduces a method that I want that is in conflict with an existing 
> method (say one taken from another CPAN module).
> 
> How should the method be aliased to prevent it from causing a conflict 
> at class composition time?

I personally don't anderstand why we don't have a exclude and alias
operator in Perl 6 but I have not read all the synopses and don't have
an overview.

In the thread "Re: YAPC::EU and Perl 6 Roles" in last july I already
said the following:
---snipp---
> The brilliant idea with "traits" is that it bring back the control to
> the class consuming the "trait" and conflicts have to be solved
> explicitly. The traits paper propose 3 different operators to solve
> such conflicts: overriding, excluding or aliasing.
> 
> I definitively think that perl 6 roles should also have an excluding
> operator because I think that *every* composition conflicts arrising
> should be solvable by the class comsuming the role.
---snapp---

As a side note, Johnatan give us a example about how to make an alias
with user defined traits, but it doesn't help here because a trait is
bound to a definition:
http://use.perl.org/~JonathanWorthington/journal/39504
My anderstanding is also that that kind of aliasing as defined with a
trait is "deep": If you alias a recursive method, the call will be done
to the aliased one (or am I wrong?).
In the original traits paper the aliasing is not "deep": to respect the
flattening property, the semantic of the role must not change, so
aliasing a recursive method will call the original method. It's a known
theoretical weakness of the traits paper and "freezing roles" try to
solve this problem.

Finally, the interaction between module and role is also interesting and
it's not clear to me how Perl 6 solve it: I send a question this August
to the mailinglist but sadly had no reply, see "Perl 6 modules and
classboxes?":
---snipp---
As Perl 6 will be supporting multiple versions installed of the same
module and also support import with lexical scoping, I was asking myself
if it was possible to combine some of the interresting properties of
classboxes like local rebinding, flattening property and the idea that
import takes precedence over inheritance.

I am absolutly not sure if it fit to the Perl 6 module concept as a
whole, but I will be happy to read your comments and what you think
about it.

A few pointers:

classboxes+traits introduction:
http://scg.unibe.ch/archive/papers/Berg05dTraitsClassbox.pdf

For an in depth description, you can also read the Ph.D. thesis:
http://scg.unibe.ch/archive/phd/bergel-phd.pdf

To develop the classbox concept, the autors also introduced a module
calculus, which also help to describe the difference existing beetween
different modules systems: (such a module calculus can also help to
better anderstand the interaction beetween different languages): 
http://scg.unibe.ch/archive/papers/Berg05cModuleDiversity.pdf
---snapp---

Raphael

Re: Aliasing methods in CPAN roles

[Raphael Descamps]

Am Montag, den 19.10.2009, 16:43 -0700 schrieb Jon Lang:
> Raphael Descamps wrote:
> > I personally don't understand why we don't have a exclude and alias
> > operator in Perl 6 but I have not read all the synopses and don't have
> > an overview.
> 
> I don't think that it's explicitly spelled out anywhere; but the
> reason is fairly straightforward: exclude and alias would break the
> interface.

You're of course right!

It's clearly explained in Apocalypse 12 (Conflict Resolution):
"A role without implementation degenerates to an interface".

I don't know why but I didn't realised before that not implementing
exclude and alias was in fact an important design decision: I have
probably read to much traits papers and not enough Apocalyses ;)

On one side you lose flexibility to resolve some composition conflicts
but the fact that a role also define a contract is of course a big win,
particulary for a language like perl 6 supporting optional statical
typing. The traits paper only focus on dynamic typing.
It also explain why perl 6 as a so strong support for delegation, as it
is the proposed way to solve composition conflicts.

It's time to read Apacalyse 12 again as I am now able to anderstand
it :)

Re: How does List.map: { .say } work?

[Raphael Descamps]

Am Montag, den 02.11.2009, 14:33 -0500 schrieb Solomon Foster:
> On Mon, Nov 2, 2009 at 2:03 PM, Solomon Foster  wrote:
> > On Mon, Nov 2, 2009 at 10:21 AM, Carl Mäsak  wrote:
> >> Solomon (>), Moritz (>>):
>  the current spec doesn't allow immutable containers to call .map with a
>  block that implicitly uses $_ as an implicit parameter.
> 
>  Here's why:
> 
>  S06 says
> 
> > The C<$_> variable functions as a placeholder in a block without any
> > other placeholders or signature.  Any bare block without placeholders
> > really has a parameter like this:
> >
> > -> $_ is rw = OUTER::<$_> { .mumble }
> 
>  So $_ is marked as rw, which is checked at binding time.
> 
>  Now lists are immutable, meaning that you can't bind a list item rw, so
>  even if the block doesn't try to modify $_, calling the { .say } block
>  fails.
> 
>  (Note that 'for' has the same problem)
> 
>  How should that be resolved? Should a temporary variable be created that
>   can be changed, without any effect? or should it fail() on detecting a
>  modification? Somehow this approach seems very backward to me...
> >>>
> >>> Is there a reason $_ is readonly isn't a possible solution?
> >>
> >> For one thing, then you couldn't do this:
> >>
> >> my @a = 1, 2, 3;
> >> for @a {
> >>  ++$_;
> >> }
> >
> > I meant, make it readonly if the container being iterated over is
> > readonly.  We're working hard to make the language prefer immutable
> > things, it seems very odd to short circuit that in a key area like
> > this...
> >
> > (Though personally, I would prefer it if map was readonly by default
> > on all containers.)
> 
> Or Larry could just find an elegant way to do it.  Yay!

FYI: Larry already found that correcting the Spec was the most elegant
solution ;)

> Author: lwall
> Date: 2009-11-02 17:31:00 +0100 (Mon, 02 Nov 2009)
> New Revision: 28973
>
> Modified:
>   docs/Perl6/Spec/S06-routines.pod
> Log:
> [S06] correct $_ placeholder binding from "rw" to "ref", moritz++

Re: You never have privacy from your children in Perl 6

[Raphael Descamps]

Am Dienstag, den 23.03.2010, 20:06 +0100 schrieb Moritz Lenz:
> 
> Carl Mäsak wrote:
> > Carl (>>), Moritz (>):
> >>>  um, so 'protected' is when the deriving classes can see the 
> >>> attribute?
> >>>  yup
> >>>  that's what 'private' means in Perl 6.
> >>
> >> That's wrong. Perl 6's "private" is like Java's "private" - subclasses
> >> can't see it.
> >> It's just Rakudo being leaky at the moment, not a fallacy of the Perl 6
> >> language. (Yes, we have failing tests for this; no, we don't run them at
> >> the moment).
> > 
> > That is indeed reassuring. Thank you.
> > 
> > ...So, how come Perl 6 doesn't have a 'protected' access level? :)

In Perl 6, you can use private attributes in submethods, so protected is
not so "badly" needed.

> Exactly for the reasons you brought up against 'protected' as a default:
> in encourages people to inherit from a class just to bypass some of the
> public API.

Apropos: I found the chapter about class declarator enlightening:

http://www.dlugosz.com/Perl6/web/class-declarators.html

(If some parts are not up-to-date, I would be happy to ear it.)

> Cheers,
> Moritz

Ciao, Raphael.

Re: r31789 -[S32] DateTime immutable, leap seconds validation

[Raphael Descamps]

Hi,

Am Freitag, den 23.07.2010, 11:50 +0100 schrieb Nicholas Clark:
> On Thu, Jul 22, 2010 at 11:54:10PM +0200, pugs-comm...@feather.perl6.nl wrote:
> 
> > It shouldn't be too hard to write a Perl 5 script, to be run as
> > part of Rakudo's build process, that automatically updates the
> > leap-second table in tai-utc.pm.
> 
> Dogfood failure.
> 
> That should be a Perl 6 script.

Been there, done that :)

See http://trac.parrot.org/parrot/ticket/619

> Yes, really, I'm serious about this, and the importance of this.
> Whilst Perl 5 isn't self-hosting, it builds a perl interpreter as early as
> possible and uses that for the rest of the build system. This
> 
> a: makes it easier for more end users to be able to fix things that hurt them,
>increasing the pool of potential core contributors
> b: ensures that the core contributors are end uses of the language they
>maintain

> I think one weakness of Parrot is that it uses almost no Parrot-based language
> in its own build system. You need to know Perl 5 or C to be useful to the
> Parrot core. And if you gain your fun by working on the Parrot core, you
> actually stop being a Parrot user, and hence experiencing what they
> experience.

Have a look at nqp-rx + kakapo + plumage + proto/PLS for some examples
where you can help without any C or Perl 5 knowledge:

http://gitorious.org/parrot-plumage
http://gitorious.net/kakapo/kakapo
http://github.com/masak/proto/tree/pls

And not to forget, the growing list of Perl 6 modules, where help is of
course always highly welcome:
http://modules.perl6.org/

Have fun, Raphael.