Getting Involved with Perl 6 - 2009

[moritz]

It's been about a year since I wrote Getting Involved with Perl 6 - an Update, and again there are many news that change how you can contribute to Perl 6 development.

Compilers

Parrot and Rakudo

Parrot has had its release of version 1.0 (and other subsequent releases, for that matter). That doesn't mean that Parrot is finished; software is never finished, and lot of works still needs to be done. But the developers now provide a relatively stable API for language developers, and the progress of Rakudo shows that many cool features can already be implemented on top of it.

Rakudo has left parrot's repository and now lives on github, has implemented many cool features (basic support for custom operators, sockets, big parts of the object system, multi dispatch, grammars) and now passes more than 10,000 tests from the official test suite (compare with my previous "getting involved" post, it was 700 back then).

But most exiting of all you can write built-in methods and functions in Perl 6 now. In the setting library (in src/setting/ there are already some methods written that way. For primitive operations inline PIR (parrot's assembly language) is used.

If you want to get involved with Rakudo, the easiest way is to either write new built-ins in Perl 6, or port existing ones from PIR to Perl 6. Send a patch to [e-mail] or contact the people in #perl6 on irc.freennode.net or at [e-mail].

Mildew

Mildew is a new Perl 6 compiler that uses STD.pm (TimToady's Perl 6 parser written in Perl 6) as a frontend and smop (a runtime library for the Perl 6 object system) as a backend. It has some nice features already (like control exceptions, modules, basic integration with Perl 5) but is not very accessible for real-world programming.

Mildew is developed in a mixture of Perl 5, Perl 6 and C, and Paweł Murias, the main developer, is glad to answer any questions on #perl6.

Elf

Elf is intended as a service for people who want to develop a Perl 6 compiler in Perl 6. Its parser is also based on STD.pm, and it is bootstrapped. Elf can emit Perl 5 and Common Lisp code.

If you are interested in writing a Perl 6 compiler in Perl 6, write a mail to [e-mail] and ask for details.

Test suite

The test suite still lives in Pugs' svn repository, and always needs love and new tests. Writing tests is a good way to get involved with Perl 6, all you need to do is to read up some Perl 6 feature and exercise it.

There's a TODO list in t/TASKS that can help you to get started. Just join #perl6 and ask for a commit bit.

Write Perl 6 modules

A lot of Perl 6 modules have been written in the last few month; Rakudo's support for classes, modules and exporting/importing subroutines has made it easy and fun.

For example there's a basic installer for Perl 6 modules, a web framework (development supported by TPF grant), a wiki engine, board game, URI parser, a blog engine, a HTTP server, xml and json parsers and a general repository with Perl 6 example code.

Writing Perl 6 modules is fun, and helps the community in several ways. It tests the compiler (usually in different ways than the test suite), it allows others to re-use your code (thus solving the problem of not having many libraries) and it encourages others to think about more involved package distribution systems.

If you think that some widely used Perl 5 modules have flaws in their interfaces or design, now is your chance to recreate them in Perl 6. The earlier a Perl 6 version exists, the likelier it is to be adopted as the standard way of solving some problem.

Websites

You can also contribute to the Perl 6 development by improving the various websites. For example perl6-projects.org perl6.org tries to keep an up-to-date overview of the current Perl 6 projects, the source can be found in the pugs repository in docs/feather/perl6.org/.

The Rakudo developers also welcome improvements to their website, ask alester or pmichaud on #perl6 for authoring privileges.

Update: perl6-projects.org is now perl6.org, udpated links accordingly.

[mj41]

See also constantly updated Perl 6 and Parrot links.

[crumbly]

I'm still a bit scared off by Perl 6 and haven't yet done much investigation. What would thaw the ice quite a bit is if there were a website that catalogued example code for doing basic things like,

• opening a file, writing something to it, and closing it
• reading in the list of files in a given directory
• doing search/replace on a string
• sorting and uniq'ing a list of strings
• basics of using hashes
• reading user input from stdin
• writing a function
• writing a simple class
• accessing environment variables
• etc.

My guess is that Perl 6 can do all sorts of amazing things, but I'd just like to see that it still makes easy things easy.

[citromatik]

What would thaw the ice quite a bit is if there were a website that catalogued example code for doing basic things like,

These examples may help you.

[moritz]

This SVN repository now lives at http://svn.pugscode.org/pugs/, the one on svn.perl.org is quite outdated. Even in the newer repository not all of these examples have been kept up-to-date with spec changes, which is why I'd recommend to look at the Perl 6 examples project instead.

Update: to avoid confusion the outdated repo on svn.perl.org has now been deleted.

[moritz]

It might please you to know that currently a student is being paid by Google's "Summer of Code" project to improve documentation infrastructure and documentation for Perl 6.

Parts of his project description:

Start writing a tutorial (see Details section above) covering basic language constructs. Write documentation about basic Perl 6 features (as specified by Synopses 2, 3, and 4), like Perl 5's perlsyn, perlop, perlfunc, and perldata. Draw on material from the relevant Apocalypses and Exegeses as well.

That should be enough to get you started, and you expect it to land mid or end of August.

[crumbly]

Oooh. Just found this: http://szabgab.com/blog/2009/06/1245164696.html. Nice.

[John M. Dlugosz]

Why not try crafting those and posting the attempts? Others will happy point out mistakes. You can annotate the listing with pointers to the synopses or discussions of the language features.

Some of those are squarely "library" and that's gotten much less attention than the core language.

Some of those lead to very interesting discussions. E.g. "environment variables" are the default values of context variables, which have taken the place of global variables.

"Perl 6 can do some amazing things" Indeed. here is one of my efforts along the lines of what I'm suggesting (which also shows reading of standard input, according to the latest decree).

—John

[crumbly]

Why not try crafting those and posting the attempts?

I'm not sure that answer makes sense here. If I was asking how to write something substantial, or even just something novel that requires a few lines of code, then it makes sense to ask me try things and post. But I'm just expressing a little curiosity about some rudimentary features of the language -- nearly trivial things to use as a reference point comparing how you'd do them in other languages. And also, making a thread about "Is this what an array looks like in Perl 6?" would probably not be of much general interest.

Yeah, I guess I could start poring over the Synopses and figuring them out. But at that point I'd have invested some substantial time when all I really had been curious about was what the Perl 6 rudiments looked like.

I guess I'm your typical "on the fence customer". If I can quickly see how easy things are easily done in Perl 6, then maybe I'll put in some time and give it a try. But at the moment, Perl 5 is working for me, and it's not easy to make free time, so I'll probably pass.

[jdrago_999]

What would Catalyst-based code look like if it were all in Perl6?

[moritz]

"like any other Perl 6 code".

No really, it's hard to tell, because Catalyst isn't ported to Perl 6 yet. Chances are that the dispatch information which is now implemented as attributes is handled with traits in Perl 6 (I remember a small web framework in Perl 6 floating around on IRC the other day that already did that), so an action method might look like this:

class YourApp::Controller is Catalyst::Controller {
   method someaction($id) is public</> {
       # executed if http://example.com/someaction is called
   }
}

Maybe the dispatch code will have an option to use the build-in multi method dispatch, which is rather powerful and serves a similar purpose.

But until somebody actually implements it, that's all just wild guesses.

[bsb]

Maybe the dispatch code will have an option to use the build-in multi method dispatch, which is rather powerful and serves a similar purpose.

Interesting idea.

My guess would've been using a dispatch grammar. Perl6 rules can be composed, ordered, re-used in different contexts, they keep track of your match in a structured way... great for unpacking the url. That doesn't really say much about the syntax though.

[John M. Dlugosz]

See http://s1n.dyndns.org/index.php/2009/05/18/dispatching-through-traits/.

[kyle]

Is there any plan to move the spectest suite into the Rakudo repository? Is there a reason not to? I understand it was originally part of the work on Pugs, and so it "belongs" there in that sense, but I thought Pugs was approximately dead and the spectests are the only action that repository gets anymore. Would it be a good idea to move the tests to some third repo that any implementation could use?

This has always seemed odd and clumsy to me.

[moritz]

Thanks for bringing it up, I'll try to summarize the current state:
• The pugs repo is used as a general repository for Perl 6 related projects. Although we still call it "pugs repo", it hosts the specification, test suite, elf, mildew, STD.pm, some infrastructural code (IRC logging, evalbot, ...). We think about renaming the repository one day.
• The test suite won't move into the rakudo repository. It is meant to be implementation agnostic, and moving it into the repo of an implementation would be counter-productive (and it's used by other programs as well, namely STD.pm and elf). Maybe I'll move it out into a completely separate repository one day.

Currently none of these issues are pressing, so I won't hurry. Especially I want to sort out the rest of the old pugs test suite before doing any kind of move. Since the easy-to-verify tests have already been moved, this is tedious work, and going to take some time. I also consider using git instead of SVN, but I'll have to wrap TimToady's head around git first ;-)

Any move will be carefully coordinated with the heads of the others projects, of course.

[kyle]

Thanks for your reply! I hope you don't mind if I have a few more questions.

I find git to be very SVN-like when using Cogito. In fact, I rarely type 'git' at all. (I guess that's more a note for TimToady than you.)

What's involved in sorting out the old Pugs test suite? Off the top of my head, I'd think that it means:

foreach my $file ( @pugs_test_files ) {
    my $new_file = reasonable_spectest_location_for( $file );
    move $file, $new_file;
    add_fudges( to => $new_file, for => $_ )
        for @perl6_implementations;
}

If I were doing this, I think the hard parts would be,

1. Figuring out where to put the new file in the spectest directory, since I'm not very familiar with the spec. (Perhaps this is a way to get familiar.)
2. Fudging anything other than Rakudo or Pugs, since I don't have them.

After that, I'm guessing it's grunt work of running the tests and seeing how they blow up to get them fudged properly for Rakudo. (Skip tests that die, and 'todo' tests that fail.) If I were doing it, I'd probably let the other implementation authors be responsible for their own fudges. Or is that rude?

Is there more involved than that?

[educated_foo]

I take it that elf no longer exists?

[moritz]

As far as I can tell, the last contributions to elf were in August 2009, and have stalled since then.