Bailamos

Since spanish classes (I mean the classes at the University, not the type definitions, you wierdo) aren’t as exciting as I would like them to be, my thoughts have wondered a bit further. Yeah, Perl 6 again. The idea isn’t new, but the point of showing off the intersting things it always fresh. So, ladies and gents, here’s a minimal part of Dancer implemented in Perl 6! To give some justice to my spanish classes, it’s not named Dancer, or even MiniDancer.


module Bailador;

use HTTP::Server::Simple::PSGI;

my @routes;

multi get(Pair $x) is export {
    @routes.push: $x;
}

sub dispatch($env) {
    for @routes -> $r {
        if $env ~~ $r.key {
            if $/ {
                return $r.value.(|$/.list);
            } else {
                return $r.value.();
            }
        }
    }
    return "404";
}

sub bailar is export {
    my $app = sub ($env) {
        my $res = dispatch($env);
        return ['200', [ 'Content-Type' => 'text/plain' ], $res];
    }

    given HTTP::Server::Simple::PSGI.new {
        .host = 'localhost';
        .app($app);
        .run;
    }
}

Although simple and stupid, it works. Let’s see some example application:

use Bailador;

# simple cases
get '/' => sub {
    "hello world"
};

get '/about' => sub {
    "about me"
};

# regexes, as usual
get /foo(.+)/ => sub ($x) {
    "regexes! I got $x"
}

get / '/' (.+) '-' (.+)/ => sub ($x, $y) {
    "$x and $y"
}

# junctions work too
get any('/h', '/help', '/halp') => sub {
    "junctions are cool"
}

bailar;

The glory of smartmatching gives as the ability to use the get() sub with regexes and junctions (and almost everything else in Perl 6 to be honest) without even thinking about it.

Now where’s named parameters, where are the other HTTP methods? Well, that is left as an excercise for the reader. I hope you’re inspired enough :)

Advertisements

Perl 6 module ecosystem – news and ideas

I’ve looked a bit into S22 recently, and I thought it would be fun to try to implement some subset of it in neutro and see how it will turn out. Well done is better than well said, so I did. More thinking on the subject and I decided to mangle the module ecosystem itself a bit to suit the new capabilities nicely. I gave life to a fork of perl6/ecosystem. How is it different? Let’s see. It no longer contains a list of the git repo urls, rather it keeps the urls of the META.info files known to it, and a script which downloads all of them and puts in a nice projects.json file containing all the metadata of the modules: descriptions, proper names (goodbye perl6-Acme-Meow, welcome Acme::Meow), dependencies, probably more eventually. But wait, what is this META.info magic? Let’s see how it looks for neutro:

{
    "name"        : "neutro",
    "version"     : "*",
    "description" : "A simple module installer for Perl 6 modules",
    "depends"     : [ "File::Tools", "Module::Tools", "JSON::Tiny" ],
    "repo-type"   : "git",
    "repo-url"    : "git://github.com/tadzik/neutro.git"
}

So all you have to do (if you want to, of course), is to create such file in the root directory in your module’s repo, let me know so I can add it to my ecosystem fork and bam! your module is now a part of the new ecosystem. Easy-peasy.

Neutro now handles the new way pretty nicely, it only needs JSON::Tiny (a new dependency: whee!) in the new ecosystem so it can bootstrap itself properly.

So, what do you think about the new way? Ideas, criticism, excitement?