Day 4 – Composers, Coercers, and the Case of a Camel’s Curious Corner

December 4, 2014 by

“Every programming language has its curious corners, it’s just that some languages’ corners are curiouser than others’.”

When viewed from space, flame wars over programming languages are all about flinging various code or other examples around in order to prompt Yet Another Potentially Awkward Explanation (YAPAE) from the other side.

Even God has to give a YAPAE every once in a while

Even God has to give a YAPAE every once in a while… [image courtesy of xkcd++]

Everyone seems to know that Perl has corners. What is perhaps less famous than these corners themselves is the fact that their YAPAEs by and large make total sense. It may be a very Perlish form of sense, quite particular to Perl 5’s associativity, context, or precedence rules, but the reasoning always works out right. The language itself has a pretty simple set of rules, it’s the interactions of those rules that any good YAPAE code snippet will actually be highlighting.

Yet if the explanation has the potential to make sense, then it is only ever potentially awkward. Behind every YAPAE is the story of a decision in language design, a place where some of the implicit rules of operation suddenly become explicit1. As such they form the intersecting seams of design choices that were made at the core language level. The explanations are never all that awkward to people who understand those choices and agree with them. I like to think of these seams in the language as “curious corners,” which refers both to the surface-level surprise that comes from a YAPAE as well as my own curiosity in the ways different languages handle their seams that show.

Perl 5 does some pretty incredible things with what syntactically amount to a few rules about precedence, associativity, and context. There’s a lot more to the language, to be sure, but when something blows up in your face it is almost one of these categories that you’ve botched. As such, almost any of syntactical surprise in Perl 5 can be solved with liberal application of parentheses. (If Perl 5 is the duct tape of the internet, then the parenthesis is the duct tape of Perl 5). These usually work together so well that you only notice them where they collide in strange ways, and once you get bitten you start to know better. That said, it was these curious corners which led to the development of a new Perl, which would have different rules and different interactions of those rules. Some of these rules exist precisely to avoid YAPAEs from previous versions.

The original text that I’m using as a source for this blog post began as something of a screed: I thought I had found a curious corner to which I was firmly on the “awkward” side of. However my opinion flipped completely about halfway through the analysis that was to form the basis of my argument. I hope by sharing the process of that reasoning with you that I can convince you of just how low the potential awkwardness of this YAPAE is.

So, join me as we explore a ‘curious corner’ of Perl 6, a journey that will take us straight to the source.

set() which is also and ().Set which is also Set()

    > Set("wise men" => 3, "star" => 1, "camels" => 9)
    set(wise men, star, camels)

    > ( "wise men" => 3, "star" => 1, "camels" => 9 ).Set
    set(wise men, star, camels)

    > set("wise men" => 3, "star" => 1, "camels" => 2)
    set("wise men" => 3, "star" => 1, "camels" => 2)

    >"wise men" => 3, "star" => 1, "camels" => 2)
    set("wise men" => 3, "star" => 1, "camels" => 2)

Well, there’s gotta be more than one way to do it, right? This is Perl, after all…

When I first ran into this, it actually upset me a fair bit. I hack in Perl at my $day_job2 and YAPAEs are a part of life when you are bringing new devs into the world of Perl. So I saw that set() and Set() both exist while also both doing different things and bit my fingernails / ranted on #perl6.

If you read that log, you can maybe tell that I’m a bit worked up. Until TimToady stated it simply: composers are not coercers.

Even though I understood the distinction more clearly, I was still a bit unconvinced and went off to investigate.

Composers like and set()

Luckily in Rakudo, investigating the internals of the language mainly implies reading how one would implement Perl 6, using Perl 6! All the examples here are taken from their respective files in src/core without modification or truncation.

First we will take a look at some behavior, and then at the code which implements it.

    > set "we wish" => "you", "a" => "merry", "camel" => "ride"
    set("we wish" => "you", "a" => "merry", "camel" => "ride")

That looks exactly like a Perl 6 subroutine invocation: calling set with an argument which is a single List of Pairs. A quick git grep 'sub set' in rakudo.git reveals this declaration:

   #~~( ) 
   sub set(*@args --> Set) { }

It appears to be some syntactic sugar, a sub which takes all of its arguments as a single list (the * prefix is ‘slurpy’) and then passes it to a constructor. I don’t know about you, but that sugar tastes guilt-free to me. Yet our investigation leads us elsewhere.

    #~~( ... is in `submethod Build`? )
    submethod BUILD (:%elems) {
        nqp::bindattr(self, Set, '%!elems', %elems);

There’s no .new definition to be found, but what is this submethod business? It sure sounds constructor related. This is a good candidate for looking up in the Perl 6 specification, which tells us that submethods are “infrastructural methods that shouldn’t be inherited by subclasses” (S12). Useful to note is that BUILD is not a phaser, but it shares Huffman coding3 with them: the all-caps is a hint that the code will run automatically.

blessed be the BUILDers

“The bless method automatically calls all appropriate BUILD routines for the current class, which initializes the object in least-derived to most-derived order,” from Synopsis 12: Objects. This is illustrated by the following snippet:

   class Elf {
        submethod BUILD { 
            say "This Elf is busy BUILDing"; 
        method new {
            say "A shiny new Elf";

    role Build { 
        method new { 
            say "Did someone want to BUILD something?";

    class Santa is Elf does Build {
       submethod BUILD { 
          say "Even Santa BUILDs";
    Did someone want to BUILD something?
    This Elf is busy BUILDing
    Even Santa BUILDs

It is the self.bless invocation in that triggers BUILDALL, which descends the inheritance chain, calling a non-inherited BUILD if it is present. Elf, which does not call self.bless in it’s new method, would only produce the following when constructed:

    A shiny new Elf

BUILD is never called here, but it will be if any descendant or role were to mix in a self.bless in a constructor. For this reason, it is generally a good idea to call self.bless when you create a new method, especially if it is in a subclass. Unless, of course, you’ve got other plans for introducing the .bless call.

Back to the investigation

So, the presence of a BUILD in our Set class means that it wants to do something special during initialization. Even though I don’t know NQP, I can guess at what this code might do by asking myself, “what does a set want to do that is so special?”

The presence of the BUILD method is interesting, but as we’ve just seen, it doesn’t do anything without a .new. Just another file over from in src/core is That looks promising, especially if we noticed class Set does Setty in and recognized the role declaration syntax.

    #~~( )
    method new(*@args --> Setty) {
        my %e;
        %e{$_.WHICH} = $_ for @args;

Well, the %e{$_.WHICH} = $_ for @args line in the new method from is already taking care of one key component of a Set: making a unique list by internally storing each element of the (again slurpy) @args in a hash. That to me implies that the NQP code is taking the other important bit: immutability. Once again we can reach into src/core to see if we can confirm that suspicion. Perl 6 has a mutable form of Set, called SetHash. Let’s check that out.

    #~~( )
    # No submethod BUILD to be found...

… so it appears that our assumption is correct! Now we know how to implement ‘hard immutability’ for an attribute in a pinch, even if we don’t have a spare second in the heat of that pinch to learn NQP.

Coercers like ().Set and Set()

Coercers are different. They don’t just flatten your lists into a big list, they reduce any Pairs in your list to just the key, or left-hand value, of any given Pair.

    > %( somehow => "special", snow => "flake" ).Set
    set(somehow, snow)

And because Any defines the .Set method, this allows a Set() call with an argument which descends from Any to coerce. If you are curious you can investigate in Synopsis 13: Overloading.

    > Set( (special => "is", as => "does") )
    set(special, as)

Note I didn’t have to turn it into a hash there. The code below shows that it will take all the thingies in the list and extract keys if it can. Otherwise it will “be on its merry,” so to speak.

    #~~( )
    method Set()     { }

    #~~( )
    method new-from-pairs(*@pairs --> Setty) {
        my %e;
        for @pairs {
            when Pair {
                %e{.key.WHICH} //= $_.key if .value;
            default {
                %e{.WHICH} //= $_;

Et voila! Coercion of a list of Pairs (or a Hash, as in the first example) no longer produces a set of Pairs as it does in the composer, but rather a set of the keys of those Pairs.

    > (special => "is", as => "does", 'a', bag 'of', 
      'snowflakes', 'snowflakes', 'snowflakes').Set
    set(special, as, a, bag(of, snowflakes(3)))

In contrast to earlier versions of Perl, 'a' does not become a key with the value of bag(of, snowflakes(3)). The difference with Perl 6 is that a Pair, denoted by the two terms separated by =>, is it’s very own type — not just a ‘fat comma’ as we have in Perl 5 (just one example of how P5 YAPAEs influenced the design of P6). The behavior is implemented by the when/default behavior: if you are a Pair, we put your key into the set. Otherwise we stuff your object as a whole in, just as we do in the composer.

    > Set( (special => "is", as => "does", 'a' => bag 'of',
      'snowflakes', 'snowflakes', 'snowflakes') )
    set(special, as, a)

Note the extra pair of parentheses when using the Set() form of the coercer. This is because Pairs are used to pass named parameters to subroutines. We can resolve this either by adding another pair of parentheses, as above, or by quoting our keys (which you can see by comparing this last snippet against the very first one in the post).


I hope that this brief, if twisty, tour of composers and coercers in the context of Set has introduced you to a few new dynamics in Perl 6. If nothing else, if it encourages an impulse to pop open src/core to perform your own investigation then I will consider it a success. A merry Christmas, and a jolly curious corner to you all!


  • 1 Why else would they result in so much cursing?
  • 2 As opposed to $day-job ;)
  • 3 We need a shorthand which represents Huffman Coding. Perhaps we can borrow a character from a logographic language with a similar associated meaning to stand in?

Day 3 – cap your junctions

December 3, 2014 by

“With great power comes great responsibility.” These days I muse on how this applies not just to movie superheroes, but to programming language features as well.

It happens all over the place. Database connection? Awesome. Well, until you become the victim of an SQL injection or a SELECT N+1 problem. Regular expressions? Also awesome… until someone uses it to parse HTML and gets a visitation from elder non-beings from beyond the fabric of reality. Ouch.

Of course, we still like our powerful features. But we need to learn to contain them, to harness them. The awesome should work for us and the purpose we have set it to. It should not work for attackers, elder non-beings, or Murphy. We need to make sure the awesome doesn’t leak beyond its designated boundaries.

In 2009, Matthew Walton blogged about junctions. His explanation of what makes junctions exciting is great, and I agree with it. Today I would simply like to add the following point: junctions are so awesome that they should be contained.

Let’s demonstrate the problem real quickly.

> my @list = 3..7
3 4 5 6 7
> my $answer = all(@list) > 0;

Quick, what value ends up in $answer? Well, all the values in @list are
indeed greater than 0, so…

all(True, True, True, True, True)

Aw, dang. Not again.

Just to be clear, this is by spec, and correctly implemented and everything. But unless you ask specifically for Perl 6 to collapse the junction, it just keeps on going. Keeps on going, like a juggernaut, through walls and oceans, propagating through your program whether you want it to or not.

What you have to do then is to collapse the junction, putting a cap on all that awesome. The junction is useful as long as you’re doing the junctive computation itself (in this case all(@list) > 0), but immediately after that, we’ll want to collapse back into the normal, sane, non-junctive world:

> ?$answer      # symbolic prefix
> so $answer    # listop prefix
> $answer.Bool  # coerce method

Moritz points out that the whole “collapsing” metaphor comes from quantum physics, where something collapses as it’s measured. The analogy holds up; after we’re done junctioning around with our “quantum” superposition, we want to get a single boolean value back out. We do that by “measuring” — boolifying — the junction.

I will hasten to add that the most common use of junctions doesn’t suffer from this problem, namely junctions in if statements:

if all(@list) > 0 {

The if statement itself provides a natural cap to the junction. It does its own boolification of it under the hood, but more importantly, the junction value doesn’t stick around. We only see the effects of the boolean value of the junction.

No, the real risk comes when you’re a library writer, and you provide routines that happen to compute things using junctions:

sub all-positive(@list) {
    all(@list) > 0;     # DANGER

That’s where you want to remember the old tired adage. With great power… comes… right, that’s right. So you cap your junction before you let it run out into the wild and do untold structural damage to people, buildings, cattle, and those cute fluffy dogs that would otherwise suffer Puppy Death By Junction.

sub all-positive(@list) {
    so all(@list) > 0;

Yes. That’s better.

If you declare your return type, you can get a runtime error for leaving out the `so`.

sub all-positive(@list --> Bool) {
    all(@list) > 0;

say all-positive([1, 2, 3]); # Type check failed for return value;
                             # expected 'Bool' but got 'Junction'

Maybe that’s an argument for declaring return types for your routines. And maybe some day we’ll catch that one at compile-time, too.

Cap your junctions as early as possible.
— masak’s Rule of Responsible Junction Use

The longest I can remember legitimately keeping junctions around in an uncollapsed state was when storing junctions of regexes in a hash as part of this password-analyzing script. Even that’s not an exception to the above rule, though — note that the first thing that happens to the junctions in the subsequent code is that they become the rhs in a smartmatch statement, and then get capped by an if statement. So even here, they don’t escape out into the wild.

Code responsibly. Cap your junctions.

Day 2 – Rakudobrew

December 2, 2014 by

Traditionally in Perl, and probably in any other scripting language (I’m going to use the term “scripting” to describe “one that requires a runtime”, bear with me) there’s quite a big discrepancy between the latest released version of the toolchain and the one that your OS distribution ships (if it ships one at all!). My Ubuntu for instance, the freshly updated 14.10 not only offers me to install a nine-month-old Rakudo 2014.03, but also one running on top of Parrot, which I don’t remember voluntarily running anytime during 2014, frankly. Even if you look at languages with a longer release cycle, like Perl 5 which releases every year, system distributions shipping old versions is still a big deal: modern Perl modules still often maintain backwards compatibility with Perl 5.8 released in 2002, because that’s what some versions of CentOS comes with.

A popular idea is to say that system Perl (or system Python, system Ruby or whatever floats your boat) is for the system itself, while we programmers can freely uses whatever version we wish as long as we install it and maintain it in our home directory and not mess with system stuff. Perl 5 people usually recommend either Perlbrew or plenv for that; in Perl 6 rakudobrew is often said to be the easiest way to stay up-to-date with recent developments.

Rakudobrew is a commandline tool that makes it easy to install and update different flavours of Rakudo, as well as switch between them any time you want to. It also updates Panda, the module installer, after every update, along with all modules you had installed before (precompiled modules need to be updated after every update of Rakudo).

I made an effort to keep rakudobrew reasonably free of dependencies: it only requires Perl 5 and git, which are roughly what’s required to build Rakudo anyway. It’s known to work well on Linuxes and OSX, but I’ve also recently got some pull requests to improve Windows support (which apparently worked for a while by itself, without me knowing about it. Cool!) so it may happen to be useful to you, our Windows-running readers just as well.

Rakudobrew requires almost zero setup to get running; the only thing you need to do is to get it from Github (either by cloning it or downloading a tarball from the website), and get your system to recognize its bin/ subdirectory as part of your PATH. What I’m usually going for on my machines is the following:

$ git clone ~/.rakudobrew
$ export PATH=~/.rakudobrew/bin:$PATH
$ echo 'export PATH=~/.rakudobrew/bin:$PATH' >> ~/.zshrc
$ # or ~/.bashrc or whatever

After that it requires nothing like ‘rakudobrew init’ or anything; it’s ready to get useful. The most basic thing you need from it is of course installing Rakudo:

$ rakudobrew build moar

The above command will download and build Rakudo on MoarVM, the latest version available from Github. For extra stability you may want to install the latest available release and just stick to that:

$ rakudobrew build moar 2014.11

This will take a while, but after a while it should finish saying “Done, moar-2014.11 built.” From that point on you are ready to go; if you adjusted your PATH correctly, the “perl6” command will be available for you to use, and you’re ready to hack!

That said, you may want something more from life than just the bare compiler. The “useful and usable” Perl 6 distribution called Rakudo Star doesn’t have its own Starbrew, but that doesn’t mean you can’t eat the cake and still have it. Let’s also install Panda, the module installer, and whatever Rakudo Star usually ships.

$ rakudobrew build panda
$ panda install Task::Star

This gets you not only the module installer (which is instantly ready to go, just as shown above), but also all the widely appreciated goodies like: NativeCall, Term::ANSIColor, DBIish or Grammar::Debugger. Life’s good!

But what if you want more from life than just MoarVM? Perhaps you want to try out the famous JVM interop? Couldn’t be easier!

$ rakudobrew build jvm
$ rakudobrew switch jvm

Contrary to what it may suggest the above commands don’t build the JVM itself (you’re expected to have that installed), but the version of Rakudo running on the Java Virtual Machine. Note that you’ll still have to install panda and all the modules you want; those are installed per every instance of Rakudo you built. In case you got lost in all the versions you installed, the list command is there to help you again:

$ rakudobrew list
* moar-HEAD

The asterisk is marking the one currently active (‘rakudobrew current’ can also tell you that). You don’t need to type the full name either; both ‘rakudobrew switch jvm’ and ‘rakudobrew switch moar-H’ will work just fine.

In case you want to get rid of something you installed (perhaps you wanted to test your code on some older version of Rakudo, or see how slow things were back in the days (the further you reach the more amazing it gets)), it’s as easy as removing a subdirectory from rakudobrew’s directory:

$ rm -rf ~/.rakudobrew/jvm-HEAD

Or in case you want to get rid of the entire rakudobrew for any reason, you don’t have to be afraid of any globally installed leftovers: there aren’t any. It’s all self-contained, so as simple as

$ rm -rf ~/.rakudobrew

And poof! Gone. Before you get rid of it though, you may want to keep your still warm Rakudo around to try out more interesting stuff that our Advent Calendar will have to show you in the coming weeks. Stay tuned!

Perl 6 Advent Calendar 2014: Table of Contents

December 1, 2014 by

This post serves as a table of contents for the 2014 Perl 6 advent calendar. Links to new posts will appear here during the course of this month.

Day 01 – The State of Perl 6 in 2014

December 1, 2014 by

Welcome to the 6th annual edition of the Perl 6 advent calendar, code name 2014.

In 2014, MoarVM has become the de facto standard backend for the Rakudo Perl 6 compiler. Parrot and JVM are still supported as backends, but MoarVM provides much lower memory usage, faster startup time, and is significantly faster than parrot at runtime.

Rakudo on MoarVM also has concurrency support, including reactive programming.

Much work has been done to improve performance, some in MoarVM, some in Rakudo and NQP. Maybe most notably is the JIT compiler for MoarVM that came out of the Google Summer of Code project by Bart Wiegmans.

Another Google Summer of Code project by Filip Sergot brought us HTTP::UserAgent, a versatile HTTP client library with SSL/TLS support.

During the Austrian Perl Workshop in fall 2014, many of the Perl 6 and Rakudo core contributors met, and identified three roadblocks for a "final" Perl 6.0 release: GLR, NFG and NSA.

Here GLR stands for the Grand List Refactoring, a plan to make the list-y types more transparent, list iteration faster, and more obvious when a list will flatten.

NFG is the Normal Form Grapheme, a plan for implementing grapheme-based string indexing.

Finally, our NSA has nothing to do with surveillance. Natively Shaped Arrays are a flexible feature for declaring typed, potentially multi-dimensional arrays, potentially with pre-defined dimensions. It will make memory-efficient matrix storage and operations possible, for example.

With these three blockers defined, Larry Wall submitted a talk to FOSDEM called Get ready to party!, predicting that 2015 will be the year that Perl 6 will get a production release.

Sorry, this was meant to become a summary of the current state of Perl 6, and it derailed into an outlook. To allow me to keep the "state" in the title, let me just tell you that Rakudo on the MoarVM is quite fun to work with. It's fast enough for small (and sometimes even mid-sized) tasks, module installation works fairly reliably, and the range of available modules has also increased.

Also I feel that any attempt to summarize the progress of this awesome community is bound to be very incomplete; I hope that my fellow Perl 6 hackers will fill in some details in the upcoming 23 posts.

Have a nice pre-Christmas time, and enjoy the show!

Day 24 – Advent Ventures

December 24, 2013 by
Here at the end of megayears of human adventure,
we schedule a silent night to stop time,
once again awaiting the next advent
of the answer to our questionable venture.

    Are we there yet?

After a gigayear or so of slogging from slime to silicon
mercifully forgetting (most of) the unmerciful past,
and the scars left by unnatural nature upon our pedigree,
we now remember to remember the future once more.

    Are we there yet?

So in this month, 26 year-moments after the advent of Perl,
(including 13 year-eternities of precocious brat sisterhood)
our little family celebrates, 24 tales at a time,
its victories in the struggle to find our way home.

    Are we there yet, Daddy, are we there yet?

We follow after all those who wander but are not lost:
We follow Abraham, looking for a city because it isn't there yet;
We follow Strider, guarding the hobbits who will redistribute the future;
We follow Magi and wizard, scholar and explorer, saint and scientist.

    I wonder as I wander out under the sky...whether I'm lost yet...

But wise man or hobbit, we must all take that journey in the dark,
groping ahead for the path to better air and a little hope,
following the encapsulated starlight past monsters and chasms
out to a land where the weary can rest, and be healed of grief.

    "Wait, what do you mean, I can't go there?" —Gandalf

We must all wander in this desert for forty years,
burying the bones of naysayers and yaysayers alike,
so that their children can someday cross the Jordan
into a land flowing with milk and honey and fancy new phones!

    "Wait, what do you mean, I can't go there?" —Moses

We carry these old stories to the future,
cadences to chant over the confusion of the road,
backpacks full of epics, pockets stuffed with tales,
leaving our own litter of anecdotal evidence behind us.

    You haven't heard some of the good ones yet.

So kids, along with the old stories, pack a few new tools,
light but powerful tools that will help you and help you help us.
The lightest tools, the most powerful tools, are ideas,
so pack lots and lots of 'em. I'll wait here while you do.

    I'm here yet. Which means I'm not there yet. Hurry up!

Pick some good friends, and let some good friends pick you.
Take turns waiting patiently, running impatiently,
or walking hopefully, crawling hopelessly,
standing up yet again defiantly. Or woozily, that works too.

    Be the protagonist some of the time, yet not all of the time.

Trust your journey to provide you with new companions;
trust your new companions to provide you with your journey.
Be prepared to say your eternal hellos and temporary goodbyes.
(No one's ever ready for the temporary hellos and eternal goodbyes.)

    And I'm not sure I want to be there quite yet.

Enjoy the companions your journey gives today, for life is bittersweet.
Enjoy the bittersweet songs and the bittersweet beer.
Enjoy the bitter fights and sweet hugs.
And, yes, enjoy the resulting bruises, but not too much.

    Enjoy knowing that you're not there yet.

Welcome, my friends, to the here, and to the not-there-yet.
Welcome to the clan's quantum superposition of joy and grief and longing.
Welcome to our ongoing effort to steal more of that Promethean fire
that burns too fast yet never fast enough to fit the firepits of our lives.

    Are we getting warmer yet?

As they say, "Give a man a fire..." Hold that thought, some breaking news...
This just in: Fire from heaven is now free and open-sourced?! Well, huh...
Seems a blogger heard some angels singing popup advent adverts in the cloud?
Hmm...better do some fact checking...hang in there...tum tiddly tum...

    Darn flakey connection...almost there...

Well, hey, whaddya know?! The physicists figured it out.
The whole universe has just finished compiling without error...
Now they're looking for someone to debug the silly thing;
Hey, I know, I'll just use the Perl 6 test suite.

    [ you have thousands of problems...]

Did you say something?

    (louder) Does sanity test #1 pass yet? What's the output?

The road goes ever on and on,
Over the river and through the woods,
You take the high road, and I'll take the low road,
We're all bound for the Promised Land.

[TimToady gets blessed and starts directing the choir of Perl Pilgrims.]
We're marching to Zion,
Beautiful, beautiful Zion,
We're marching upward to Zion, that beautif—

    You can't go there.

Wait, what do you mean, I can't go there?

    Bugfix #1: kill all the bad poets.


Day 23 – Unary Sort

December 23, 2013 by

Most languages or libraries that provide a generic sort routine allow you to specify a comparator, that is a callback that tells the sort routine how two given elements compare. Perl is no exception.

For example in Perl 5, which defaults to lexicographic ordering, you can request numeric sorting like this:

 use v5;
 my @sorted = sort { $a <=> $b } @values;

Perl 6 offers a similar option:

 use v6;
 my @sorted = sort { $^a <=> $^b }, @values;

The main difference is that the arguments are not passed through the global variables $a and $b, but rather as arguments to the comparator. The comparator can be anything callable, that is a named or anonymous sub or a block. The { $^a <=> $^b} syntax is not special to sort, I have just used placeholder variables to show the similarity with Perl 5. Other ways to write the same thing are:

 my @sorted = sort -> $a, $b { $a <=> $b }, @values;
 my @sorted = sort * <=> *, @values;
 my @sorted = sort &infix:«<=>», @values;

The first one is just another syntax for writing blocks, * <=> * use * to automatically curry an argument, and the final one directly refers to the routine that implements the <=> "space ship" operator (which does numeric comparison).

But Perl strives not only to make hard things possible, but also to make simple things easy. Which is why Perl 6 offers more convenience. Looking at sorting code, one can often find that the comparator duplicates code. Here are two common examples:

 # sort words by a sort order defined in a hash:
 my %rank = a => 5, b => 2, c => 10, d => 3;
 say sort { %rank{$^a} <=> %rank{$^b} }, 'a'..'d';
 #          ^^^^^^^^^^     ^^^^^^^^^^  code duplication

 # sort case-insensitively
 say sort { $^ cmp $^ }, @words;
 #          ^^^^^^     ^^^^^^  code duplication

Since we love convenience and hate code duplication, Perl 6 offers a shorter solution:

 # sort words by a sort order defined in a hash:
 say sort { %rank{$_} }, 'a'..'d';

 # sort case-insensitively
 say sort { .lc }, @words;

sort is smart enough to recognize that the code object code now only takes a single argument, and now uses it to map each element of the input list to new values, which it then sorts with normal cmp sort semantics. But it returns the original list in the new order, not the transformed elements. This is similar to the Schwartzian Transform, but very convenient since it's built in.

So the code block now acts as a transformer, not a comparator.

Note that in Perl 6, cmp is smart enough to compare strings with string semantics and numbers with number semantics, so producing numbers in the transformation code generally does what you want. This implies that if you want to sort numerically, you can do that by forcing the elements into numeric context:

 my @sorted-numerically = sort +*, @list;

And if you want to sort in reverse numeric order, simply use -* instead.

The unary sort is very convenient, so you might wonder why the Perl 5 folks haven't adopted it yet. The answer is that since the sort routine needs to find out whether the callback takes one or two arguments, it relies on subroutine (or block) signatures, something not (yet?) present in Perl 5. Moreover the "smart" cmp operator, which compares number numerically and strings lexicographically, requires a type system which Perl 5 doesn't have.

I strongly encourage you to try it out. But be warned: Once you get used to it, you'll miss it whenever you work in a language or with a library that lacks this feature.

Day 22 – A catalogue of operator types

December 22, 2013 by

Perl 6 has a very healthy relationship to operators. "An operator is just a funnily-named subroutine", goes the slogan in the community.

In practice, it means you can do this:

sub postfix:<!>($N) {
    [*] 2..$N;
say 6!;    # 720

Yeah, that’s the prototypical factorial example. I promise I won’t do it any more in this post. I swear the only reason we don’t have factorial as a standard operator in the language, is so that we can impress people by defining it.

Anyway, so a postfix operator ! is really just a "funnily-named" subroutine postfix:<!>. Similarly, we have prefix and infix operators, like prefix:<-> and infix:<*>. They’re all just subroutines. I wrote about that before, so I’m not going to hammer on that point.

Operators have different precedence (like infix:<*> binds tighter than infix:<+>)…

$x + $y * $z   # compiler sees $x + ($y * $z)
$x * $y + $z   # compiler sees ($x * $y) + $z

…and different associativity (like infix:</> associates to the left but infix:<=> associates to the right).

$x / $y / $z   # compiler sees ($x / $y) / $z
$x = $y = $z   # compiler sees $x = ($y = $z)

But I wrote about that before too, at quite some length, so I’m not going to revisit that topic.

No, today I just want to talk about the operator categories in general. I think Perl 6 does a nice job of describing the operator types themselves. I don’t see that in many other languages.

Here are all the different types:

 type            position           syntax
======          ==========         ========

prefix          before a term        !X
infix           between two terms    X ! Y
postfix         after a term         X!

circumfix       around               [X]
postcircumfix   after & around       X[Y]

A lot of other languages give you the ability to define your own operators. Many of them provide approaches which are hackish afterthoughts, and only allow you to override existing operators. Some other languages do approach the problem head-on, but end up simplifying the language to decrease the complexity of defining new operators.

Perl 6 approaches, and solves, the problem, head-on. You get all of the above operators, you can refine or override old ones, and you can talk within the language about things like precedence and associativity.

All that is rather nice. But, as usual, Perl 6 goes one step further and starts classifying metaoperators, too.

What’s a metaoperator? That’s our name for when you can extend an operator in a certain way. For example, many languages allow some kind of not-equal operator like infix:<!=>. Perl 6 has another one for string non-equality: infix:<ne>. And then maybe you want to do smart non-matching: infix:<!~~>. And so on — pretty soon you catch on to the pattern: you may, at one point or another, want to invert the result of any boolean matcher. So that’s what Perl 6 provides.

Here are a few examples:

normal op     negated op
=========     ==========
eq            !eq     ( synonym of ne )
~~            !~~
<             !<      ( synonym of >= )
before        !before

Because this particular metaoperator attaches itself before an infix operator, it gets the name infix_prefix_meta_operator:<!>. I was going to say "and yes, you can add your own user-defined metaoperators too", but currently no implementation supports that. Maybe sometime in the future.

There are many other categories of metaoperators. For example the "multiplication reducer" [*] that we used in the factorial example at the top (which takes a list of numbers and multiplies them all together) is really an infix:<*> surrounded by the metaop prefix_circumfix_meta_operator:sym<[ ]>. (It’s "prefix" because it goes before the list of numbers.)

Luckily, we don’t have meta-meta-ops. Already thinking about the metaops is quite a challenge sometimes. But what I like about Perl 6 and the approach it takes to grammar and operators is this: someone did think about it, long and hard. The resulting system has a pleasing simplicity to it.

Perl 6 is very well-suited for building parsers for languages. As one of its neatest tricks, it takes this expressive power and directs it towards the task of defining itself. As a Perl 6 user, you’re given not just an excellent toolbox, but a well-organized workshop to adapt and extend to fit your needs.

Day 21 – Signatures

December 21, 2013 by

In today’s post, we’ll go through the basics of Perl 6’s subroutine signatures, which allow us to declare our parameters instead of coding them as we do in Perl 5.

In Perl 5, arguments to a sub are accessible via the @_ array, so if you want to access an argument to a sub, you can either access the array directly (which is typically only done where speed is a concern)…

use v5;
sub greet {
    print "Hello, " . @_[0] . "\n";

Or, more commonly, pull off any arguments as lexicals:

use v5;
sub greet {
    my $name = shift @_;
    print "Hello, $name\n";


Perl 6 lets you declare required positional arguments for your subs as part of the signature:

use v6;
sub greet($name) {
    print "Hello, $name\n";

Inside the sub, $name is available as a readonly alias to the passed in variable.

By default, parameters are required. If you try to call this function with no parameters as greet, you’ll get a compile time error:

Calling 'greet' requires arguments (line 1)
Expected: :($name)

You can make the parameter optional by adding a ? to the signature. Then you’ll have to examine the parameter to see if a defined value was passed in. Or, you can declare a default value to be used if none is passed in:

use v6;
sub guess($who, $what?) {
    # manually check to see if $what is defined

sub dance($who, $dance = "Salsa") {
dance("Rachael", "Watusi")

Another way to handle optional arguments is to use multis. Multis are subs that can have multiple implementations that differ by their signature. When invoking a multi, the argument list used in the invocation is used to determine which version of the multi to dispatch to.

use v6;
multi sub dance($who, $dance) {
    say "$who is doing the $dance";
multi sub dance($who) {
    dance($who, "Salsa");


The parameters in the previous section allow any type of value to be passed in. You can declare that only certain types are valid:

sub greet(Str $name) {
    say "hello $name";

Now hello("joe") will work as it did before. But hello(3) will generate a compile time error:

Calling 'greet' will never work with argument types (int) (line 1)
Expected: :(Str $name)

In addition to any of Perl 6 builtin types or user-built classes, you can also add programmatic checks inline in the signature with where clauses.

use v6;
multi odd-or-even(Int $i where * %% 2) { say "even" };
multi odd-or-even(Int $i) { say "odd"};

Note that we didn’t have to add a where clause to the second sub. The multi-dispatch algorithm will prefer the more detailed signature when it matches, but fallback to the less descriptive version when it doesn’t.

You can even use literal values as arguments. This style allows you to move some of your logic to the multi dispatcher.

use v6;
multi fib(1) { 1 }
multi fib(2) { 1 }
multi fib(Int $i) { fib($i-1) + fib($i-2) }

say fib(10);

Note that this isn’t very efficient… yet. Once the is cached trait for subs is implemented, we can use that to provide a builtin analog to Perl 5’s Memoize module.


Perl 6 provides for named parameters; if the positionals are analogous to an array of parameters, the named arguments are like a hash. You use a preceding colon in the argument declaration, and then pass in a pair for each parameter when invoking the sub.

use v6;
sub doctor(:$number, :$prop) {
    say "Doctor # $number liked to play with his $prop";
doctor(:prop("cricket bat"), :number<5>);
doctor(:number<4>, :prop<scarf>);

Note that the order the parameters are passed in doesn’t matter for named parameters.

If you have a variable of the same name in the calling scope, you can simplify the calling syntax to avoid creating an explicit pair.

use v6;
my $prop = "fez";
my $number = 11;
doctor(:$prop, :$number)

You can also use different names internally (using the expanded pair syntax) for the named arguments. This allows you to use different (simplified or sanitized) versions for the caller.

use v6;
sub doctor(:number($incarnation), :prop($accoutrement)) {
    say "Doctor # $incarnation liked to play with his $accoutrement";
my $number = 2;
my $prop = "recorder";
doctor(:$number, :$prop)


To support functions like sprintf, we need to be able to take a variable number of arguments. We call these args “slurpy”, since they “slurp” up the arguments.

# from rakudo's src/core/
sub sprintf(Cool $format, *@args) {

When invoking this sub, the first argument must be of type Cool (kind of a utility supertype), and all the remaining positional arguments are slurped up into the @args variable. The preceding * indicates the slurp.

Symmetrically, we can also slurp up named arguments into a hash.

# from rakudo's src/core/
my &callwith := -> *@pos, *%named {

This snippet introduces to the pointy block syntax for anonymous subs. The -> begins the declaration, followed by the signature (without parentheses), and finally the sub definition in the block. The signature here shows all the positionals ending up in *@pos, and all the named arguments in %named.

This also shows that positionals and named arguments can be combined in the same sub.


Method and sub declarations are virtually identical. All the parameters mentioned so far are usable in methods.

The main difference is that methods can be passed an invocant (the object associated with the method call), and when you define the sub, you have the opportunity to name it. It must be the first parameter if present, and is marked with a trailing :.

use v6;
method explode ($self: $method) {...}

Note that there is no comma separating these the invocant and the first positional. In this context, the colon functions as a comma.

Parameter Traits

Each parameter can additionally specify a trait that changes the behavior of that parameter:

  • is readonly – this is the default behavior for a parameter; the sub cannot modify the passed in value.
  • is rw – the argument can be modified. Forces the argument to be required.
  • is copy – the sub gets a modifiable copy of the original value.

More Information

Check out Synopsis #6 for more information, and the roast test suite for more examples – any of the directories starting with S06-.

Day 20 – How to mangle the initial state

December 20, 2013 by

The past year saw the (at least partial) implementation of several variable traits. But before we get into that, the past year also saw Nil getting implemented closer to spec in Rakudo. If you read the spec, you will know that Nil indicates the absence of a value. This is different from being undefined, as we saw in an earlier blogpost this year. So what does that mean?

$ perl6 -e 'my $a = 42; say $a; $a = Nil; say $a'

So, assigning Nil will reset a scalar container to its default value, which (by default) is the type object of that container. Which is (Any) if nothing is specifically specified.

Enter the “is default” variable trait

If you want to specify the default value of a variable, you can now use the “is default” variable trait:

$ perl6 -e 'my $a is default(42); say $a; say $a.defined’

So oddly enough, even though we haven’t assigned anything to the variable, it now has a defined value. So let’s assign something else to it, and then assign Nil:

$ perl6 -e 'my $a is default(42) = 69; say $a; $a = Nil; say $a'

Of course, this is a contrived example.

“is default” on arrays and hashes

It gets more interesting with arrays and hashes. Suppose you want a Bool array where you can only switch “off” elements by assigning False? That is now possible:

$ perl6 -e 'my Bool @b is default(True); say @b[1000]; @b[1000]=False; say @b[1000]'

Of course, type checks should be in place when specifying default values.

$ perl6 -e 'my Bool $a is default(42)'
===SORRY!=== Error while compiling -e
Type check failed in assignment to '$a'; expected 'Bool' but got 'Int’

Note that this type check is occurring at compile time. Ideally, this should also happen with arrays and hashes, but that doesn’t happen just yet. Patches welcome!

Using is default on arrays and hashes interacts as expected with :exists (well, at least for some definition of expected :-):

$ perl6 -e 'my @a is default(42); say @a[0]; say @a[0].defined; say @a[0]:exists'

Note that even though each element in the array appears to have a defined value, it does not necessarily exist. Personally, I would be in favour of expanding that to scalar values as well, but for now :exists does not work on scalar values, just on slices.

It’s not the same as specifying the type

What’s wrong with using type objects as default values? Well, for one it doesn’t set the type of the variable. Underneath it is still an (Any) in this case:

$ perl6 -e 'my $a is default(Int) = "foo"; say $a'

So you don’t get any type checking, which is probably not what you want (otherwise you wouldn’t take all the trouble of specifying the default). So don’t do that! Compare this with:

$ perl6 -e 'my Int $a = "foo"'
Type check failed in assignment to '$a'; expected 'Int' but got 'Str'

Which properly tells you that you’re doing something wrong.

Nil assigns the default value

Coming back to Nil: we already saw that assigning it will assign the default value. If we actually specify a default value, this becomes more clear:

$ perl6 -e 'my $a is default(42) = 69; say $a; $a = Nil; say $a'

In the context of arrays and hashes, assigning Nil has a subtly different effect from using the :delete adverb. After assigning Nil, the element still exists:

$ perl6 -e 'my @a is default(42) = 69; say @a[0]; @a[0] = Nil; say @a[0]:exists'

Compare this with using the :delete adverb:

$ perl6 -e 'my @a is default(42) = 69; @a[0]:delete; say @a[0]; say @a[0]:exists'

One could argue that assigning Nil (which assigns the default value, but which is also specced as indicating an absence of value) should be the same as deleting. I would be in favour of that.

Argh, I want to pass on Nil

The result of a failed match, now also returns Nil (one of the other changes in the spec that were implemented in Rakudo in the past year). However, saving the result of a failed match in a variable, will assign the default value, losing its Nilness, Nilility, Nililism (so much opportunity for creative wordsmithing :-).

$ perl6 -e 'my $a = Nil; say $a'

It turns out you can specify Nil as the default for a variable, and then It Just Works™

$ perl6 -e 'my $a is default(Nil) = 42; say $a; $a = Nil; say $a'


You can use the VAR macro to introspect variables to find out its default value, without having to do something as destructive as assigning Nil to it:

$ perl6 -e 'my @a is default(42); say @a.VAR.default'

This also works on system variables like $/:

$ perl6 -e 'say $/.VAR.default'

And can also be used to interrogate other properties:

$ perl6 -e 'say $/.VAR.dynamic’

But this gets us into material for a blog post for another day!


The “is default” variable trait allows you to manipulate the default value of variables and elements in arrays and hashes. Together with the new meaning of Nil, it is a powerful means of mangling initial values of variables to your satisfaction.


Get every new post delivered to your Inbox.

Join 49 other followers