Writing mod_perl6 in Perl 6

One of the goals of the mod_parrot project is to provide the infrastructure for running the Perl 6 version of mod_perl, a.k.a. mod_perl6. I've already demonstrated that mod_perl6 works, so that goal is slowly being achieved. Many thanks to Patrick Michaud, Jerry Gay, and everyone else who has worked on the Parrot implementation of Perl 6.

Another lesser known goal of mod_parrot is to allow the high level language (HLL) layers to be written in the HLL itself. That is to say, write mod_perl6 in Perl 6. Up to this point, mod_parrot has five HLL layers (PIR, NQP, Perl6, PHP/Plumhead, Perl1/Punie), all written in Parrot's native PIR. However, yesterday, with some help from Patrick, I was able to port mod_perl6 from PIR to pure Perl 6!

As an example, here is a very bare-bones mod_perl6 (DISCLAIMER: string interpolation in namespaces doesn't actually work yet):

module ModParrot::HLL::perl6;

our %loaded_modules;

# load a Perl 6 handler module
sub load($module)
{
    unless (%loaded_modules{$module}) {
        use $handler;
        %loaded_modules{$module} = 1;
    }
}

# call a Perl 6 response handler
sub handler($name)
{
    my $r = Apache::RequestRec.new();
    load($name);
    my $status = ::($name)::handler($r);
    $status;
}

# call a Perl 6 authentication handler
sub authen_handler($name)
{
    my $r = Apache::RequestRec.new();
    load($name);
    my $status = ::($name)::handler($r);
    $status;
}

When calling a Perl 6 handler, mod_parrot loads this module and calls the individual handler routines according to the Apache configuration. It also provides the interface to Apache, including the Apache::RequestRec class needed by mod_perl6. Everything else it leaves to the Perl 6 compiler.

You might think this code doesn't actually do much, and that's the point. It's really just a simple thunking layer between mod_parrot and your handlers, enforcing the rules of the mod_perl6 implementation. For example, in mod_perl, an Apache::RequestRec object is passed to all response handlers. This layer is responsible for making sure that happens.

As the Perl 6 compiler matures and mod_parrot adds more functionality, this version of mod_perl6 will inevitably change. But what you see above will remain at its core -- loading Perl 6 modules, juggling arguments, and passing control to handler subroutines. And the fact that it's pure Perl 6 will enable scores of Perl programmers to hack on it without having to know anything about Parrot or C programming. Take that, XS.

Very good work! I'll look into this. A question and a comment: Will mod_perl6 be more like mod_perl or mod_perl2? Maybe now is the opportunity to make mod_perl more "high level", like easier reading of POSTs into hashes with length limits, returning compressed content easier, reading/setting cookies and session handling without third parties and also stealing the best parts of php (which I hate, but some small pieces are good).

Thanks for the kind words. :) As for mod_perl6, I'm trying not to influence the design too much, just putting together the infrastructure to make it happen faster. Personally, I don't want to see mod_perl "dumbed down", but we do have some pain points we can address now that we're starting from the ground up, such as the issues you mentioned. I think the key is to keep the core simple and maintainable, bundle in the right modules, and provide good documentation right from the start. In other words, we have a lot of work to do!

As the Perl 6 compiler matures and mod_parrot adds more functionality, this version of mod_perl6 will inevitably change. It is evident.