In the past week, I’ve improved my Tags library to handle more common cases and be easier to use, I migrated HTTP::Daemon to use Parrot sockets instead of exec-ing socat, and I wrote a basic pastebin: http://github.com/masak/web/blob/c84c4c1892463459e406958db8f9232e7b7bf5d1/bin/kopipasta.pl.

You might be able to see a running instance here: http://pleasedieinafire.net:2080/. That host has poor connectivity lately, though.

I’ve also played a bit with some ideas related to dispatch. Here’s an example I got working on the plane home from Boston:

use LolDispatch;
use HTTP::Daemon;
sub item($request, $match) is handler(/^\/item\/(\d+)/) {
    say 'dispatched to item';
    say $match.perl;
}
my $request = HTTP::Request.new(
    req_url => HTTP::url.new(path => '/item/12345'),
    headers => HTTP::Headers.new( header_values => { 'Host' => 'localhost' }),
    req_method => 'GET',
);
dispatch($request);

Here’s the output of that example:

dispatched to item
Match.new(
 # WARNING: this is not working perl code
 # and for debugging purposes only
 ast  => "/item/12345",
 text => "/item/12345",
 from => 0,
 to   => 11,
 positional => [
  Match.new(
     ast  => "12345",
     text => "12345",
     from => 6,
     to   => 11,
    ),
 ],
)

I've got the start of a simple port of Template Declare implemented. It's not perfect, and I'm still working out the API we want, but it's functional, and nice. It's quite a bit nicer than CGI.pm-style html generation.

The philosophy of this library is that templates are code, and we should be able to deal with them as such. If your template is Perl, you can use all of the same tools you use for Perl. No need to learn a new language, and far fewer angle brackets. :)

Here's an example that runs under the current Tags.pm. Keep in mind, there's still a decent amount of API refactoring needed.

use Tags;
say show {
    html {
        head { title { 'Tags Demo' } }
        body {
            outs "hi";
            ul :id<numberlist> {
                outs "A list from one to ten:";
                for 1..10 {
                    li :class<number>, { $_ }
                }
            }
        }
    }
}

I also added a hackish implementation of the :lang parameter to Perl 6's eval that loads up the appropriate compiler to use instead of the Perl 6 compiler. This means that Rakudo can now do things like this:

eval(q<VISIBLE "O HAI GUYZ">, :lang<lolcode>);
my $x = eval(q<10×5÷2>, :lang<APL>);
my $rubysub = eval(q<do |i| puts "ruby got " + i; return i + 10 end>, :lang<cardinal>);
my $schemesub = eval(q<(lambda (msg) (write "scheme got " msg "\n"))>, :lang<pheme>);
$schemesub($rubysub($x));

The output of that is:

O HAI GUYZ
25
ruby got 25
scheme got 35

The extra '25' is there because the APL spec says that any non-assignment results in a print as a side-effect.

I haven't added support for this to any of the other Parrot languages yet because I don't know what the API should look like for any other language.

I haven't added support for loading foreign libraries to Perl 6 yet because there are a couple of awkward semantic issues to work out, and I haven't added support for loading foreign libraries to any other language yet because I don't know what the API should look like.

This is where you come in, my opinionated Internet friends. If you have suggestions for the API for evaluating foreign code or loading foreign libraries in any of Ruby, Python, LOLCODE, PHP, or any other Parrot language, please speak up here or on the social news site of your choice.

Thanks go to my employer for sponsoring my work on Parrot. Most of what I've done wouldn't be possible without their support.

I checked on IRC today during a break in the class I'm teaching to see jhorwitz asking for currying in Perl 6, which is spelled like:

my $curried = &function.assuming(...);

A few minutes later, I committed an implementation of it. Here is the currying patch for Rakudo. It's about the same size as the last patch I mentioned here. Here are the tests we're now passing:

sub tester(:$a, :$b, :$c) {
"a$a b$b c$c";
}

my $u = &tester.assuming(b => 'x');
is $u(a => 'w', c => 'y'), 'aw bx cy', 'currying one named param';

my $w = &tester.assuming(b => 'b');
my $v = $w.assuming(c => 'c');
is $v(a => 'x'), 'ax bb cc', 'can curry on an already curried sub';
is $w(a => 'x', c => 'd'), 'ax bb cd', '... and the old one still works';

All of the code in this blog entry is in PIR (Parrot Intermediate Representation, Parrot’s equivalent of ASM).

Throwing an exception from Parrot is pretty straightforward:

.sub main :main
    $P0 = new 'Exception'
    throw $P0
.end

If you want a message on the exception, a severity, etc, it’s like this:

.sub main :main
    $P0 = new 'Exception'
    $P0 = "I couldn't foo. :("
    $P0['severity'] = .EXCEPT_ERROR
    throw $P0
.end

Catching an exception isn’t much harder:

.sub main :main
    push_eh handler
    function_that_could_fail()
    pop_eh
    .return (1)
  handler:
    .get_results ($P0)
    say "Couldn't foo because some function failed"
    .return (0)
.end

That function just returns failure if an exception was thrown between ‘push_eh’ and ‘pop_eh’. Pretty straightforward.

If you wanted to actually recover from the exception and resume continuation, we can do this too. Parrot adds a continuation to the exception object that you can invoke to resume execution at the next opcode after you threw the exception:

.sub main :main
    push_eh handler
    maybe_fail()
    pop_eh
    .return (1)
  handler:
    .local pmc exception, continuation
    .get_results (exception)
    cleanup_and_recover()
    continuation = exception['resume']
    continuation()
.end

There’s a potential problem here with what happens when something in the exception handler, such as the ‘cleanupandrecover’ function we imagined here, throws an exception. When this exceptions system was first implemented, the handler would just catch the exception again, the handler would misbehave again, infinite loop. Bad.

The solution that has been in place for quite a while is to mark the exception handler as “already used” and then to have exception handlers refuse to handle anything if they had already been used. This doesn’t play nicely with resumable exceptions. For example, this code:

.sub main :main
    .local pmc e
    push_eh handler
    e = new 'Exception'
    e = "First Exception"
    throw e
    e = new 'Exception'
    e = "Second Exception"
    throw e
    pop_eh
    say "Everything was fine."
    .return ()
  handler:
    .local pmc ex, co
    .get_results (ex)
    print "Caught exception with message: "
    say ex
    co = ex['resume']
    co()
.end

Currently produces this output:

[sweeks@kweh parrot]$ ./parrot exception-demo.pir
Caught exception with message: First Exception
Second Exception
current instr.: 'main' pc 16 (exception-demo.pir:9)

Parrot can’t find a valid handler for the exception, so it prints the message and the file/line-number it was thrown on and dies.

The currently-used workaround for this is to make an actual ExceptionHandler object and manually mark the exception handler as unused before invoking the resume continuation. This is ugly.

.sub main :main
    .local pmc eh, e
    eh = new 'ExceptionHandler'
    set_addr eh, handler
    push_eh eh
    e = new 'Exception'
    e = "First Exception"
    throw e
    e = new 'Exception'
    e = "Second Exception"
    throw e
    say "Everything was fine."
    pop_eh
    .return ()
  handler:
    .local pmc ex, co
    .get_results (ex)
    print "Caught exception with message: "
    say ex
    eh = 0
    co = ex['resume']
    co()
.end

This works, though:

[sweeks@kweh parrot]$ ./parrot exception-demo.pir
Caught exception with message: First Exception
Caught exception with message: Second Exception
Everything was fine.

To deal with this ugliness, I added the ability to set a filter for exception types or severities on exception handlers a while back. That works like the following:

.include 'include/except_severity.pasm'
.sub main :main
    .local pmc eh, e
    eh = new 'ExceptionHandler'
    set_addr eh, handler
    eh.'min_severity'(.EXCEPT_NORMAL)
    eh.'max_severity'(.EXCEPT_WARNING)
    push_eh eh
    e = new 'Exception'
    e = "First Exception"
    e['severity'] = .EXCEPT_NORMAL
    throw e
    e = new 'Exception'
    e = "Second Exception"
    e['severity'] = .EXCEPT_WARNING
    throw e
    say "Everything was fine."
    pop_eh
    .return ()
  handler:
    .local pmc ex, co
    .get_results (ex)
    print "Caught a warning: "
    say ex
    co = ex['resume']
    co()
.end

That example will only work on parrot r32783 or newer, due to a small bug I just fixed.

So, this ‘disable exception handler’ behavior is very simple to remove. We’ve left it in so long because there are still a few tests that rely on the old behavior. We’re looking to remove it soon, though.

That’s about it for the basics of using exceptions in Parrot. Soon I’ll post about the bug in Parrot that made resuming to another subroutine not work.