As most of you probably know, unless you came here via a link from java.net, I write a summary every week of the ongoing developments on the Perl 6 development mailing lists. Which means, if nothing else, that my review of Perl 6 Essentials by Randal, Sugalski & Tötsch might be just a little partial.

Any book which aims to hit a target as mobile as Perl 6 and Parrot is always going to have a hard time, but the writers are all intimately involved in their design and development, so they’re going to be closer to the mark than most. Allison Randal is a member of the core team designing Perl 6 the language; Dan Sugalski is the project leader for Parrot and Leopold Tötsch, generally described in my Perl 6 Summaries as the Patch Monster has a phenomenal work rate and knows Parrot inside out.

The book opens with a short overview of the genesis of Perl 6 and how the project is structured and managed, and how you can get involved in the various subprojects. Included in this section is an overview of how Perl 6 the language is being designed. One of the criticisms that’s been levelled at Perl 6 is that it’s being designed by a committee. However, this isn’t the way most of the people involved in Perl 6 see it. The language is being designed by Larry Wall, with direct support from Damian Conway, Allison Randal and the others on the core team. Meanwhile mailing list participants pitch in with new ideas, questions, clarifications etc. It might look like there’s a lot of noise and disparate voices if you’re watching the mailing lists, but it’s very apparent from reading the design documents that Larry puts out (The Apocalypses) that Larry is the designer of Perl 6. There’s a distinctive Wallian feel to them that’s very different from the stuff produced on the mailing lists, and even from the stuff Damian Conway did in his Perl 5+i effort. It’s quite weird—often I’ll see an idea on the mailing list and think “No, that’s just going too far.”, then along comes Larry in the next Apocalypse and he’s taken the idea I’d previously rejected, pushes it even further and comes back with something that’s powerful, Perlish and broadly useful.

Ahem, I digress.

Next up is an overview of the Perl 6 design philosophy. If you’ve seen Allison speaking about this at OSCON or YAPC then much of the material in this chapter will be familiar (I do find myself wondering which came first, the talk or the chapter). This is a well written, thoughtful explanation of the principles underlying the language design. In a sense, this chapter can be thought of as an essence of Perl—There is very little in here that doesn’t apply equally to earlier Perls, possibly right back to Perl 0.whatever. Even if you’re not particularly interested in Perl 6 (or even Perl) there’s a good deal to think about here—the importance of considering natural languages when designing programming languages, and of giving the program the freedom to express her intent in several ways (and the responsibility to choose the clearest option of course)—there’s certainly plenty of meat for the Lambda the Ultimate and LL1 crowds.

Chapter 4 covers the syntax of Perl 6. It’s written as if it’s an early draft of the Perl 6 edition of Programming Perl. I really like this chapter, it covers an awful lot of ground and it does so with admirable clarity. The most obvious change is Larry’s total rethink of the pattern matching syntax, which is a fantastic piece of work and no mistake, but a no less important change (to my way of thinking at least) is the changes in the way blocks work.

If you listen to the likes of Mark Jason Dominus (and if you don’t listen to Mark, you really should) you’ll be aware of the importance that he places on Perl’s very high level capabilities, particularly its functional programming capabilities. Well, in Perl 6, functional programming just got a whole lot less wordy. And with tail call elimination on the cards, it should be getting faster too.

The shift to function signatures which name the arguments helps to reduce the ‘noise’ in the body of the the subroutine. Hoisting parameter naming into the signature gets rid of all the tedious manipulation of @_ that characterises every single subroutine block in Perl. I sometimes think that the parameter handling folderol is one of the main reasons that too many Perl 5 functions and methods stay long and don’t get factored into small, comprehensible units of code.

Perl 6 has also dropped the requirement to use sub to declare anonymous subroutines, making it far easier to write methods and functions that can be used as if they were part of the language. And hey, it’s four characters less to type every time you call a higher order function or method. It doesn’t sound like much, but if you go and take a look at Ruby or Smalltalk and the way in which so many of those languages’ powerful constructs make heavy use of syntactically light blocks. See Exegesis 6 for a very good set of examples covering almost everything to do with subroutines, methods and blocks.

Also in this chapter is coverage of Perl 6’s replacement for Perl Compatible Regular Expressions. Wow. If I were a Python or Ruby evangelist, then I’d currently be busy stealing the ideas and syntax in the new Perl 6 Rules and trying to get something up and running before Perl 6 does. The new Perl 6 Rules/Grammar system is a comprehensive rethink of how pattern matching works and should work. As I’ve mentioned in an earlier entry, I went to Damian Conway’s talk on Perl 6 Rules at OSCON this year, and he showed off a partial implementation (in Perl 5) and they’re phenomenal parsing tools. That afternoon, I rode in Ward Cunningham’s Jeep back from Portland Zoo and we talked about Perl 6 rules. I may not have got my Ward number down to 1 at OSCON, but I can say that Ward seemed excited by the possibilities inherent in the new rules system. He’s not alone.

The rest of the book is concerned with Parrot, Perl 6’s target VM. Unlike Perl 6, Parrot is available to download and run today. It’s not finished, but it’s becoming more capable as every day passes (thanks in no small part to Leo Tötsch’s phenomenal workrate, and, in recent weeks, Michal Wallace’s sterling work on getting Python up and running on Parrot). This does mean that the Parrot section of the book has a few inaccuracies where Parrot has changed the way it works. My favourite is found in the discussion of Coroutines on p93 where Dan writes “Coroutines can be implemented in terms of continuations if need by, but that requires using a full continuation-passing function call system, something we choose not to do”. Well, that’s what most copies say; Mine has a signed correction from Dan as I believe that particular statement was out of date about a day after too book went to press. There aren’t many of these however, and I’d be worried if there weren’t any — good design arises from experience, and there aren’t too many people with experience of writing a register based VM. Overall, the Parrot Internals chapter is strong on the structure of Parrot, and offers insight into the why of it. If you intend to help with the task of implementing Parrot then this is an excellent place to start; you’ll still have to read the source, and the detailed design documents, but if you’ve read this you’ll have a good map in your head of how things hang together.

The last two chapters are concerned with writing assembly programs to run on Parrot. Essentially the would be language implementer can either write all his code in native Parrot Assembly Language, managing register allocations and the like himself and generally getting all those associated headaches. Or, he can write code for IMCC using Parrot Intermediate Language (known as PIR for reasons that aren’t entirely clear even to one who has been watching the mailing list since the Parrot project started) which is an ‘overlay’ on top of PASM. IMCC handles all your register allocation needs, implements macros, handles the parrot callling conventions and generally makes the poor compiler writer’s life easier. The idea is that IMCC will provide language independent optimizations such as automatic inlining of function calls, loop unrolling and (eventually) the whole arsenal of assembly level optimization tricks that have been developed down the years. All you have to do is write your compiler/interpreter reasonably simply and let IMCC handle the bookkeeping. But, I’m getting ahead of myself again.

Reading the chapter on Parrot Assembly Language can be a strange experience, especially if you’re used to ‘real’ assembly languages. It starts off gently, looking pretty much like ‘real’ machine code, but with the odd wrinkle that there seems to be no way of accessing the main memory, and there’s PMCs to worry about that don’t look like anything you’d get in a ‘real’ assembler—what was the last chip you saw with a fully functioning sprintf opcode? The chapter finishes with a handy reference of Parrot ops and how to use them, which is excellent; I generally don’t have sufficient screen real estate to go tracking through doc files in search of something, but a book open beside you is a godsend. Parrot Assembly is a remarkably powerful and expressive assembly language, but for anything serious you should really press on to the next chapter, which covers IMCC.

IMCC is great. Although it was intended as a target for compilers that didn’t want to have to worry about the register allocation bookkeeping, it’s also a very pleasant environment in which to write your own code. Again, this section of the book is well written and makes a very handy reference. Last but not least is a decent index (given the speed with which this book was put together I’m amazed that it has an index, let alone a decent one.)

Perl 6 Essentials has had a somewhat mixed reception in various places. The major criticism (from those who have neither read it nor intend to read it) is along the lines of “Even by the most optimistic estimates, Perl 6 is at least a couple of years away, why do we need this book?” Well, yes, Perl 6 is at least a couple of years away, but Parrot (or something very like it) is here right now and it’s supporting some ‘real’ programming languages, not just toys like BASIC and Python, it can even host Brainfuck and Befunge. If you want to start targetting Parrot, then this book is a great place to start.

The Perl 6 half of the book is important too. Allison has pulled together the existing Apocalypses and Exegeses, taken the various changes that have happened since they were written and boiled the state of Perl 6 down into a straightforward and readable description of where we stand. From the feedback I’ve been getting about my weekly Perl 6 Summaries, I know that there are plenty of people out there who are interested in what’s going on in Perl 6, but who don’t have the time to read the mailing lists. I don’t doubt that there are also people out there who are interested in Perl 6 but who don’t have time to read the summaries for whom this book would also be ideal.

I do wish it had larger margins though. I can see this becoming a book that I end up covering with annotations and addenda as the language changes with each new Apocalypse, Exegesis, Parrot Design Document and large patch from Leo Tötsch. And I do wonder if it wouldn’t have been better entitled The Perl 6 Annual 2003.