Parrot

Announcing the Parrot Foundation

2008-06-24T10:30:00.000-07:00

On June 9th, 2008, we filed the incorporation papers for the Parrot Foundation (abbreviated as just "Parrot", or "PaFo" if you can't resist the shiny alphabet soup). The articles of incorporation and bylaws were drafted on the mailing list and in the wiki, the same way all Parrot design documents are drafted. The design of the foundation is very much a part of the design of the whole project, tailored to the culture and customs of Parrot.

The purpose of the foundation is to hold the intellectual property of the project, to help drive development of the core codebase and language implementations, to support and grow the community around Parrot, and reach out to other language projects. As we push through the final steps to the 1.0 release, the foundation will provide the infrastructure we need to move forward.

The initial board of directors consists of: Allison Randal, Chairman; Jerry Gay, President; Will Coleda, Vice President; Shane Warden, Secretary; and Jeff Horwitz, Treasurer. The membership of the foundation will start with the current committers, and quickly expand to include all contributors. Members elect the board of directors every year, so the leadership and direction of the foundation is always guided by the developers.

It's exciting to see the foundation come together so quickly and smoothly. While the idea of a foundation for Parrot has been bubbling on the back burner for about a year, it was only two months ago that we got together and decided it was time to make it a reality.

Thanks to all who have helped make it possible, and cheers to a great future!

Parrot Hackathon and Workshop at YAPC::NA 2008

2008-06-22T17:44:00.000-07:00

Many parrot committers attended the recent YAPC:NA; we scheduled a pre-conference hackathon that turned out to be very effective. Thanks to the conference hosts for keeping us floating in caffeine and snacks.

More than the closed tickets and committed code, the face to face time with the other committers is always a plus. Working with someone online is very different than a face to face meeting, and can lay the groundwork for future collaboration efforts.

Jim Keenan drove a workshop at the conference, a new format that provides an extended, freeform timeslot. Jim used the workshop to get everyone there to build both parrot and Rakudo. We were able to get most of the folks there building on their respective platforms. For those who did encounter difficulties, we were able to get some bug reports (and some fixes), and even some patches from those new to the project. (Packy++ and Deven++)

I even got someone potentially interested in partcl (Tcl on Parrot) out of the workshop, a bonus I was not expecting. (Shane++).

Hopefully we can recreate some of this success at YAPC::EU, and definitely next year at YAPC::NA '09. See you then!

Parrot workshop at YAPC::NA 2008 -- success!!

2008-06-19T19:03:00.000-07:00

Yesterday at YAPC::NA 2008 we had a Parrot workshop, primarily organized by Jim Keenan. It went great -- Jim did a fantastic job. I think we had approximately 20 participants total, and several of the parrot folks came by to help.

During the workshop I think we managed to get nearly everyone with a working copy of Parrot and Rakudo Perl, and I even managed to take some notes on how we can improve things for others later.

We also found (and fixed) some bugs in the official test suite, and Deven Corzine even grabbed a Pugs commit bit and fixed a Windows bug in the fudgeall script!

I found the workshop to be very productive for me personally, and again my compliments and thanks to Jim Keenan and the other organizers for putting it together. (I was at the workshop to help, but I didn't do much of the work in putting it together. :-)

Pm

Parrot 0.6.3 "Beautiful Parrot" Released!

2008-06-17T11:19:00.000-07:00

Greetings,

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.3 "Beautiful Parrot." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 0.6.3 is available via CPAN (soon), or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code.

Parrot 0.6.3 News:

- Specification
+ updated pdd09_gc.pod
- Languages
+ Cardinal:
 - dramatically improved parsing speed
 - added support for defining and instantiating classes
 - started fleshing out the builtin class hierarchy
 - added support for hashes and arrays
+ Chitchat: added the start of a smalltalk compiler
+ Pheme: updated to match PGE changes
+ Pynie: return statement, other minor updates
+ Rakudo:
 - added working list and hash contexts
 - added 'return' statements
 - added => pair constructor
 - added ?? !! ternary
 - added Range, range operators, Complex
 - added common List, Hash methods
 - refactored base classes
 - added Mutable, Perl6Scalar classes
 - added type-checking, is readonly/rw/copy for parameters
 - added make localtest, docs/spectest-progress.csv
 - fix named unaries
+ Squaak: implement return statement
+ Tcl: updated control flow exceptions to use new builtin types
- Compilers
+ All tools converted to P6object metamodel
+ PGE:
 -  is now a zero-width match
 - reduced backtracking to improve parsing speed
+ PCT:
 - added "return" PAST.op node type for subroutine returns
 - added "keyed_int" scoping to PAST::Var
 - fixed calls to closures
 - automatically transcode 7-bit unicode to ascii for faster processing
+ NQP: added "return" statement, ?? !! ternary operator
- Configuration
+ expanded step gen::opengl
- Implementation
+ updated function and macro names to match pdd09_gc.pod
+ removed Super PMC
+ add ".namespace []" as alternative to ".namespace"
+ "make codetest" target runs standard coding tests
- Miscellaneous
+ added P6object class for Perl 6 interfaces to objects in Parrot
+ ported OpenGL/GLU/GLUT bindings to Win32, BSD, and more Mac OS X variants
+ generate OpenGL/GLU/GLUT bindings by parsing system headers
+ new OpenGL example shapes.pir, covering basic OpenGL 1.1 / GLUT 3 APIs
+ new float4.pir structure-packing benchmark
+ reduced memory use for variables
+ improved constant string caching
+ made code g++ and gcc (with optimizations) safe
+ the usual collection of bugfixes and optimizations

Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 15 July 2008.

Enjoy!
./smash

YAPC::NA Hackathon

2008-06-13T21:45:00.000-07:00

I know we have at least 5 parrot hackers here at YAPC::NA in the dorms, ready to start hacking at nine-ish Chicago-time tomorrow.

If you're at YAPC, feel free to swing by; If you're on IRC, please join us tomorrow in #hackathon or #parrot in irc.perl.org.

For an overview of what's on the agenda, see:

http://conferences.mongueurs.net/yn2008/wiki?node=ParrotHackathon

See you there!

Implementing the 'return' statement in Squaak

2008-06-11T06:48:00.001-07:00

Recently, Patrick Michaud made first steps to extend the Parrot Abstract Syntax Tree (PAST) to handle return statements. In this short report, I'll show how to implement a return statement in Squaak, the PCT tutorial language we created earlier. First, however, we'll have a quick review of why implementing 'return' is not straightforward. Parrot has these fancy calling conventions, right? So why not just use the .return directive?

The reason for this is that the PCT implements blocks (or scopes) as PIR subroutines. Consider the following Squaak code snippet:

sub foo() 
  do
     do
       return 42
     end
  end
end

The subroutine foo translates to three different blocks, or scopes: one for each do-end pair, and one for the subroutine itself. Each block is represented by a PIR subroutine, which are nested (using the PIR :outer flag, if you were curious). I'll not go into details, because I'm sure this will be explained in more detail by others later on, but I just want to explain the basics here.
When a .return directive is executed by Parrot, it will return to the calling subroutine. As the foo subroutine above consists of three subroutines, the return statement above will return to its outer block (which invokes its nested block), and not to the caller of the foo subroutine.

Instead of using the .return directive, Parrot will use the exceptions subsystem to implement control constructs such as return statements. Now, as I predicted before, I'm sure someone will explain all this in much more detail, but for now, we just want to get an idea how to actually use all this and implement a return statement. So let's not talk any longer, and look at how to do this.

First, we should extend the grammar of Squaak. As the return statement is a statement, add an alternative to the statement rule, like so:

rule statement {
   ...
   | <return_statement> {*}  #= return_statement
}

rule return_statement {
   'return' <expression>
   {*}
}

In order to allow for syntax like "x = foo()", we need to extend the rule for term. Note that sub_call should come before primary. (Once Longest Token Matching is implemented, this is no longer necessary).

rule term {
   ...
   | <sub_call>   #= sub_call
   | <primary>    #= primary
   ...
}

Now, that was easy huh? Let's look at the actions. The action method for statement will just dispatch to the action method in the key specified after #=.

method return_statement($/) {
    my $expr := $( $<expression> );
    make PAST::Op.new( $expr,
                       :pasttype('return'),
                       :node($/) );
}

If you read the PCT tutorial, this code should be easy to read. First, we get the result object for the expression. Then we create a new PAST::Op node, this time of the new pasttype 'return'.
Now, you might think this is all, but not quite. We have to specify that the block representing the subroutine is doing the actual returning. This is done using the following line of code in the action method for sub_definition:

$past.control('return_pir');

So, now we have implemented the return statement in Squaak, let's see what happens. Rebuild Squaak, and start the Squaak interpreter in interactive mode:

$ ../../parrot squaak.pbc

Now type:

sub main() return 42 end x = main() print(x)

You could also store this in a file, and then specify the file when running the Squaak compiler, but this is easier for now. After hitting return (no pun intended), you'll see:

> 42

Isn't the Parrot Compiler Toolkit a fabulous tool?

P6object: Perl 6 metaclasses for Parrot

2008-05-31T13:36:00.000-07:00

A week or so ago I worked on creating a new metaclass library ("P6object") for use by Rakudo and the other compiler tools. It replaces the Protoobject.pbc and other metaclass components that those tools had previously been using. This article provides some background and details about the library.

Background

The P6object library is based heavily on the Perl 6 object model described in Synopsis 12. Perl 6's default object model looks a lot like a standard class-based model when it's used in typical programming, but it also has some important differences.

One key feature of Perl 6's OO model is the concept of "prototype objects", or "protoobjects" for short. A protoobject is an "empty" or undefined instance of a class that proxies as a "generic instance" for the class as a whole. In other words, the protoobject for a class allows us to reason about and calculate what an instance of the class can do without having to have a defined instance of that class. For this reason Synopsis 12 talks about protoobjects as being the "class object" -- i.e., it's the thing you use when you want to talk generically about the class. In fact, Perl 6 doesn't have a mandatory Class type, it's all done with protoobjects and metaclasses (we'll cover metaclasses in a bit).

The most common use for a protoobject is to create a new object:

    class Dog { 
        method bark() { say "Woof!"; }
    }

    my $fido = Dog.new();

Another common use of protoobjects is to test 'isa' or 'does' semantics:

    if $fido ~~ Dog  { ... }

In the cases above we use the name "Dog" to indicate a class, but whereas Parrot and other languages would take "Dog" to be a Class object that defines the attributes and methods for objects in the class, in Perl 6 the "Dog" symbol above refers to an instance of the Dog class that reports itself as being undefined -- i.e., a protoobject.

If you're now thinking "all this protoobject stuff is making things complicated" -- don't worry. Most of the time a Perl 6 programmer won't have to think about protoobjects -- just do the natural thing (as in the examples above) and it all works out correctly.

We can use .WHAT on any object to obtain the protoobject for the object's type. One use for a protoobject is to get a stringified form of the (short) name of the type.

    say $fido.WHAT;         # "Dog\n"

So, now that we know something about protoobjects, what's a metaclass? Well, a metaclass is the compiler's underlying representation of a class. Synopsis 12 doesn't say a lot about how metaclasses work internally, leaving those details up to the implementation. But any time we want to manipulate the class itself, such as adding an attribute or determining the available methods, we use a metaclass to do it. We get to the metaclass of an object by using .HOW:

    $fido.HOW.methods()     # get the methods list for $fido
    Dog.HOW.attributes()    # get the attribute list for Dog objects

Using P6object

Okay, with that background in mind, let's look at the P6object implementation. From this point I'll be using PIR for my examples, because that's what I expect most people using P6object will be using. However, it's nearly all method calls and symbol table lookups, so it's relatively easy to follow, and of course one can access the library from NQP or Rakudo.

First, to load the library one uses the load_bytecode opcode:

    load_bytecode 'P6object.pbc'

Of course, if a program has already loaded PGE or PCT, then the P6object library is already loaded. Once the library has been loaded, we can access the P6metaclass object and use it to create a new class:

    .local pmc p6meta
    p6meta = get_hll_global 'P6metaclass'
    p6meta.'new_class'('Dog', 'attr'=>'legs tail')

This creates a new class called "Dog", and creates attribute slots named "legs" and "tail". Methods for the new class are defined the same way it's done in normal PIR -- decorate a sub in the appropriate namespace with ":method":

    .namespace ['Dog']
    .sub "bark" :method
        say "Woof!"
    .end

Once the class is created, we can get its protoobject and use that to create a new instances of the class. So, to do the PIR equivalent of the Perl 6

    $fido = Dog.new();
    $fido.bark();

one would write in PIR

    .local pmc dogproto, fido
    dogproto = get_hll_global 'Dog'
    fido     = dogproto.'new'()
    fido.'bark'()                    # "Woof!\n"

Note that the new class exists as a normal Parrot class -- i.e., one can still create new Dog objects by using the new opcode or the Dog parrot class via get_class. But once a decision is made to use P6object, it may be better to stick with its defined interfaces for metaprogramming operations. More on this below.

To create a subclass of an existing class, simply supply a "parent" argument to the new_class method:

    ##  Perl 6:
    ##      class Beagle is Dog { ... }
    ##      $snoopy = Beagle.new();

    .local pmc beagleproto, snoopy
    p6meta.'new_class'('Beagle', 'parent'=>'Dog')
    beagleproto = get_hll_global 'Beagle'
    snoopy      = beagleproto.'new'()

Classes created using new_class always have P6object as one of the ancestor classes, which defines default .WHAT and .HOW methods for all objects. Thus:

    ##  Perl 6:
    ##      say $snoopy.WHAT;

    $P0 = snoopy.'WHAT'()       # get snoopy's protoobject
    $S0 = $P0                   # stringify it
    say $S0                     # "Beagle\n"

Methods such as .isa, .can, and .does are defined on the metaclass for each object (as described in Synopsis 12).

    ##  Perl 6:
    ##      $i = $snoopy.HOW.can('bark');
    ##      $i = $snoopy.HOW.isa('Dog');

    $P0 = snoopy.'HOW'()        # get snoopy's metaclass
    $I0 = $P0.'can'('bark')     # see if snoopy can bark
    $I0 = $P0.'isa'('Dog')      # see if snoopy is a Dog

If the name of a class is segmented using double-colons, then P6object automatically places the protoobject in the appropriate Parrot namespace:

    p6meta.'new_class'('NQP::Grammar::Actions')

    $P0 = get_hll_global 'NQP::Grammar::Actions'        # wrong
    $P0 = get_hll_global ['NQP';'Grammar'], 'Actions'   # right

So, what do we gain from all of this? First, it provides a Perl 6-like foundation for all of the objects used in the Perl 6-related compiler components, including PCT, PGE, NQP, and Rakudo. Thus, each of these tools knows that the objects coming from another component support the Perl 6 metaprogramming model, which aids consistency. Also, most metaprogramming operations are method based, which means the tools can use a single access paradigm (method calls) to do their metaprogramming, instead of having to work with an irregular set of PIR opcodes with varying operand types.

One key aspect of P6object that has particular importance to Rakudo Perl is that P6object can add Perl-6 like roles to Parrot's existing classes and built-in PMC types. For example, Perl 6 expects to work with 'Int', 'Str', and 'Num' objects, but other libraries in Parrot might return values that are 'Integer', 'String', or 'Float' PMCs. Since checking and autoboxing every value could get cumbersome and/or expensive, P6object allows us to give Perl 6 object model behaviors to existing classes. This is done using the 'register' method on P6metaclass:

    p6meta.'register'('Float')

This line creates a protoobject for Parrot's built in Float type, and adds .WHAT and .HOW methods to Float objects. The protoobject also gives us a .new method for building Float PMCs:

    .local pmc floatproto
    floatproto = get_hll_global 'Float'
    $P0 = floatproto.'new'()

Of course, the old way of creating Float objects in PIR still works:

    $P0 = new 'Float'
    $P0 = 6.28318

And, as mentioned above, Floats receive the .WHAT and .HOW methods that all P6objects have:

    $P1 = $P0.'WHAT'()
    $S1 = $P1
    say $S1                    # "Float\n"

The "name" option to .register and .new_class causes the protoobject to be created using a different name:

    p6meta.'register'('ResizablePMCArray', 'name'=>'List')

    .local pmc list
    list = new 'ResizablePMCArray'               # create a RPA
    $P1  = list.'WHAT'()                         # get the protoobject
    $S1  = $P1                                   # stringify it
    say $S1                                      # "List\n"

This is useful for mapping Parrot's built-in types to HLL-specific class
names.

Note that registering a class doesn't mean that new "List" will work in PIR, because Parrot still thinks of the class as "ResizablePMCArray". But using the protoobject for List will do what we want:

    .local pmc listproto, list
    listproto = get_hll_global 'List'
    list = listproto.'new'()

We can also register classes to use a specific protoobject instead of creating a new one:

    ##  create a subclass of Hash called MyHash
    p6meta.'new_class'('MyHash', 'parent'=>'Hash')

    ##  register existing Hash class as being MyHash
    .local pmc myhashproto
    myhashproto = get_hll_global 'MyHash'
    p6meta.'register'('Hash', 'protoobject'=>myhashproto)

This has the result of causing all Parrot Hash objects to report themselves as instances of "MyHash", and to return the same protoobject for 'MyHash' and 'Hash' objects.

Finally, the "parent" argument to .register cause the named parent class(es) to be added as parents of the class being registered. If the class being registered is a built-in PMC type or otherwise cannot have parent classes added, then the methods of the parent classes are composed into the class directly.

Thus the following causes Hash objects to return the MyHash protoobject and metaclass in response to .WHAT and .HOW, and adds all of the methods of MyHash to the existing Hash PMC type (unless Hash already has such methods).

    p6meta.'register'('Hash', 'parent'=>'MyHash', 'protoobject'=>'MyHash')

Summary

The P6object library provides quite a few other features for managing and manipulating classes, and new features such as roles, attribute management, and method exporters are in the works. With these features, P6object provides a robust Perl 6-like interface to Parrot's underlying object model.

Parrot 0.6.2 "Reverse Sublimation" Released!

2008-05-20T12:45:00.000-07:00

They were walking to the Hemlock, the Rooster and the Mice, and
the Mice kept looking at one another, questioning.
"We don't know what the future holds, do we?" said Chauntecleer. The Mice all shook their heads. They knew very little of anything. "If," said Chauntecleer, "I say, if I don't come back again, then you must make this food to last a long, long time. I trust your prudence, don't I?" he asked, and they nodded automatically, but their eyes were very big. "And I trust your integrity, right?" They nodded. "And you are mature, now, and I respect your maturity, isn't that so?" Poor Mice, they nodded and nodded, and they blinked, and they nodded. They looked afraid. "Good," said Chauntecleer. "I know I won't be disappointed."
In this way he gave each Mouse a manhood. They couldn't talk to him just now, having so much to turn over in their minds. But neither did they cry.

— The Book of Sorrows, by Walter Wangerin Jr.

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2
"Reverse Sublimation." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 0.6.2 is available via CPAN (soon), or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on our source code repository to getthe latest and best Parrot code.

Parrot 0.6.2 News:

Specification
- updated and launched pdd28_strings.pod
- updated pdd19_pir.pod
Implementation
- added implementation of Rational PMC
- simplified ops control flow syntax
- enabled backtrace on non-glibc platforms too
- improved some PIR error reporting
- removed user stack opcodes (save, restore, lookback, entrytype, depth, rotate_up)
  (NOTE: This was scheduled to occur after 0.7.0, moved up to this release)
- removed register stack, saveall, and restoreall opcodes
- removed various deprecated features and unused code
Languages
- Amber: retired
- C99: grammar updated
- Cardinal: resurrected, method calls and do blocks work now
- Eclectus: use NQP as PAST generating code
- Lua:
  - added big number library
  - updated to match PGE changes
  - added a bytecode disassembler & a Lua 5.1 VM bytecode translator
- Pheme: updated to match PGE/PCT changes
- Plumhead:
  - use NQP as PAST generating code
  - use riaxpander for macro expansion
- Rakudo:
  - updated ROADMAP
  - conditional and loop statement modifiers
  - lots of class, object, role, and method improvements
  - Str increment and decrement
  - improved spectest reporting
  - type checking on assignment
  - regexes and grammars
  - undef and self
  - placeholder vars
- Squaak: added to repository
- TAP: retired
Compilers
- PGE: updated to match Synopsis 5, deprecated features removed
- PCT:
  - improve handling of register types, conversion between registers
  - improved error diagnostics
  - add 'arity' to for loops
Configuration
- added step auto::opengl
- added step gen::opengl
- added step gen::call_list
Miscellaneous
- still more optimizations and performance improvements, especially in GC
- new libraries: OpenGL/GLU/GLUT bindings (small subset working)
- new dump_pbc.pl utility: PBC disassembly/source code weaver
- improved C++ compiler support
- optimized builds work again

Gracias to all our contributors for making this possible, and our sponsors for supporting this project. The next scheduled release will occur on 17 June 2008.

Enjoy!

Parrot Bug Day, 17 May 2008

2008-05-13T12:08:00.000-07:00

The next monthly Parrot release will take place next Tuesday, 20 May 2008. In preparation for the release, we're holding yet another monthly Bug Day, all day Saturday 17 May. Parrot hackers, contributors, fans, and hangers-on will gather in #parrot on irc.perl.org to discuss proposed patches, verify and close bugs, and help potential new contributors download, configure, build, and understand Parrot and languages hosted in the Parrot repository. If you're interested in Parrot, have some free time, and want to get your hands a little bit dirty with code, please join us. You don't need to know how to program C or PIR or even Perl 5, but knowing how to download code from a public Subversion repository and build a C program will be very helpful.

700 Ticket Challenge...

2008-05-08T06:06:00.000-07:00

… whoops, you missed it.

chromatic challenged parrotteers on Tuesday to get the number of open/new tickets in RT down to 700 before he cuts the monthly release on May 20th. As of now, we're down to 698, twelve days early!

This is still a lot of tickets, but there's still a lot of simple cleanup that can be done.

Bug reports on old versions of parrot. We are now releasing code every month, and there's a good chance that a bug reported on a previous version no longer exists, or has changed presentation. Try to duplicate the issue with svn-latest or the most recent dev release, and add a note indicating if you could for your platform/revision.
Apply patches! If you're not sure if a patch should be applied, you can still help by trying to apply it to trunk and see if it even applies cleanly; if not, reply to the requester (and the parrot mailing list) asking them to rebase their patch and resubmit it.
Triage TODO items. Many of the TODO items came from XXX comments in the code. Check to see if this is an actual coding task, or something that can be solved by a simple documentation patch.
Close tickets! Sometimes a ticket will end up getting resolved via comments in email (saved as history on the ticket), but a bug admin simply hasn't gotten around to closing the ticket yet. If you're not a bug admin, you can ping the parrot-porters mailing list at perl.org or let us know on IRC (#parrot on irc.perl.org)

Keeping a better handle on what we have in our issue list helps us know how much work is left before we get to 1.0.

So, even if you're not comfortable with hacking on parrot guts, consider helping out with the queue. This can free up those hackers to spend more time implementing features and fixing bugs.

And if you are comfortable, feel free to grab a bug and dig in!

Thanks!

Output of Episode 9's Game of Life

2008-04-08T17:54:00.000-07:00

In Episode 9, the source code for John Conway's Game of Life was posted. If you don't feel like doing exercises or just want to see what it looks like without doing any trouble, here's what it looks like (this is life generation 9).

-----------------------------------------
-----------------------------------------
-----------------------------------------
-----O-----------------------------------
----OO-----------------------------------
--OO--O----------------------------------
-----OO----------------------------------
--OOOOO------------------OOO-------------
------------------------O---O------------
-----------------------O-----O-----------
----------------------O---O---O----------
----------------------O--O-O--O----------
----------------------O---O---O----------
-----------------------O-----O-----------
------------------------O---O------------
-------------------------OOO-------------
-----------------------------------------
-----------------------------------------
-----------------------------------------
-----------------------------------------
-----------------------------------------

Life - generation: 9

But really, it doesn't compare to seeing this program run on Parrot :-)

Update: The sources for Squaak have been added to the Parrot repository. Update your local copy today, run Configure, build Squaak, and run "../../parrot squaak.pbc examples/life.sq".

Solutions to the PCT Tutorial Exercises

2008-04-08T07:08:00.001-07:00

Below you can find links to the solutions to the exercises of the PCT tutorial.
Episodes 1 and 2 didn't have any exercises.

Solutions to the Exercises of Episode 8

2008-04-08T06:45:00.001-07:00

1. We've shown how to implement keyed variable access for arrays, by implementing the action method for index. The same principle can be applied to keyed access for hashtables. Implement the action method for key.

method key($/) {
my $key := $( $<expression> );

make PAST::Var.new( $key, :scope('keyed'),
                         :vivibase('Hash'),
                         :viviself('Undef'),
                         :node($/) );
}

2. Implement the action methods for array_constructor and hash_constructor. Use a PAST::Op node and set the pasttype to 'call'. Use the "name" attribute to specify the names of the subs to be invoked (e.g., :name("!array") ). Note that all hash fields must be passed as named arguments. Check out PDD26 for doing this, and look for a "named " method.

method named_field($/) {
    my $past := $( $<expression> );
    my $name := $( $<string_constant> );
    ## the passed expression is in fact a named argument,
    ## use the named() accessor to set that name.
    $past.named($name);
    make $past;
}

method array_constructor($/) {
    ## use the parrot calling conventions to 
    ## create an array, 
    ## using the "anonymous" sub !array 
    ## (which is not a valid Squaak name)
    my $past := PAST::Op.new( :name('!array'), 
                              :pasttype('call'), 
                              :node($/) );
    for $<expression> {
        $past.push($($_));
    }
    make $past;
}

method hash_constructor($/) {
    ## use the parrot calling conventions to 
    ## create a hash, using the "anonymous" sub 
    ## !hash (which is not a valid Squaak name)
    my $past := PAST::Op.new( :name('!hash'), 
                              :pasttype('call'), 
                              :node($/) );
    for $<named_field> {
        $past.push($($_));
    }
    make $past;
}

3. We'd like to add a little bit of syntactic sugar for accessing hashtable keys. Instead of writing foo{"key"}, I'd like to write foo.key. Of course, this only works for keys that do not contain spaces and such. Add the appropriate grammar rule (call it "member") that enables this syntax, and write the associated action method. Make sure this member name is converted to a string.
Hint: use a PAST::Val node for the string conversion.

rule postfix_expression {
| <key> {*}         #= key
| <member> {*}      #= member
| <index> {*}       #= index
}

rule member {
'.' <identifier>
{*}
}

method member($/) {
my $member := $( $<identifier> );
## x.y is syntactic sugar for x{"y"},
## so stringify the identifier:
my $key    := PAST::Val.new( :returns('String'),
                            :value($member.name()),
                            :node($/) );

## the rest of this method is the same
## as method key() above.
make PAST::Var.new( $key, :scope('keyed'),
                         :vivibase('Hash'),
                         :viviself('Undef'),
                         :node($/) );
}

Solutions to the Exercises of Episode 7

2008-04-08T06:32:00.000-07:00

1. Currently, Squaak only has grammar rules for integer and string constants, not floating point constants. Implement this grammar rule. A floating-point number consists of zero or more digits, followed by a dot and at least one digit, or, at least one digit followed by a dot and any number of digits. Examples are: 42.0, 1., .0001. There may be no whitespace between the individual digits and the dot. Make sure you understand the difference between a "rule" and a "token".

token float_constant {
    [
    | \d+ '.' \d*
    | \d* '.' \d+
    ]
    {*}
}

2. Implement the missing operators: (binary) "-", "<=", ">=", "==", "!=", "/", "%", "or"

For sake of completeness (and easy copy-paste for you), here's the list of operator declarations as I wrote them for Squaak:

rule expression is optable { ... }

proto 'infix:or' is precedence('1')
                 is pasttype('unless') { ... }
proto 'infix:and' is tighter('infix:or')
                  is pasttype('if') { ... }

proto 'infix:<'   is tighter('infix:and') { ... }
proto 'infix:<='  is equiv('infix:<') { ... }
proto 'infix:>'   is equiv('infix:<') { ... }
proto 'infix:>='  is equiv('infix:<') { ... }
proto 'infix:=='  is equiv('infix:<') { ... }
proto 'infix:!='  is equiv('infix:<') { ... }

proto 'infix:+'   is tighter('infix:<')
                  is pirop('n_add')   { ... }
proto 'infix:-'   is equiv('infix:+')   
                  is pirop('n_sub')   { ... }

proto 'infix:..'  is equiv('infix:+')   
                  is pirop('n_concat') { ... }

proto 'infix:*'   is tighter('infix:+') 
                  is pirop('n_mul')     { ... }
proto 'infix:%'   is equiv('infix:*')   
                  is pirop('n_mod')     { ... }
proto 'infix:/'   is equiv('infix:*')   
                  is pirop('n_div')     { ... }

proto 'prefix:not' is tighter('infix:*')   
                   is pirop('n_not')   { ... }
proto 'prefix:-'   is tighter('prefix:not')
                   is pirop('n_neg')   { ... }

proto 'term:'      is tighter('prefix:-') 
                   is parsed(&term)      { ... }

Solutions to the Exercises in Episode 6

2008-04-03T08:40:00.000-07:00

Without further ado, the solution to the exercise in Episode 6:

1. By now you should have a good idea on the implementation of scope in Squaak. We haven't implemented the for-statement yet, as it needs proper scope handling to implement. Implement this. Check out Episode 3 for the BNF rules that define the syntax of the for-statement. When implementing it, you will run into the same issue as we did when implementing subroutines and parameters. Use the same trick for the implementation of the for-statement.

First, let us look at the BNF of the for-statement:

for-statement ::= 'for' for-init ',' expression [step]
                  'do'
                  block
                  'end'

step          ::= ',' expression

for-init      ::= 'var' identifier '=' expression

It's pretty easy to convert this to Perl 6 rules:

rule for_statement {
    'for' <for_init> ',' <expression> <step>?
    'do' <statement>* 'end'
    {*}
}

rule step {
    ',' <expression>
    {*}
}

rule for_init {
    'var' <identifier> '=' <expression>
    {*}
}

Pretty easy huh? Let's take a look at the semantics. A for-loop is just another way to write a while loop, but much easier in certain cases. This:

for var <ident> = <expr1>, <expr2>, <expr3> do
   <statement>*
end

corresponds to:

do
  var <ident> = <expr1>
  while <ident> <= <expr2> do
     <statement>*
     <ident> = <ident> + <expr3>
  end
end

If <expr3> is absent, it defaults to the value "1". Note that the step expression (expr3) should be positive; the loop condition contains a "<=" operator. When you specify a negative step expression, the loop variable will only decrease in value, which will never make the loop condition false (unless it overflows, but that's a different issue; this might even raise an exception in Parrot; this I do not know). Allowing negative step expressions introduces more complexity, which I felt was not worth the trouble for this tutorial language.

Note that the loop variable <ident> is local to the for loop; this is expressed in the equivalent while loop by the surrounding do/end pair: a new do/end pair defines a new (nested) scope; after the "end" keyword, the loop variable is no longer visible.

Let's implement the action method for the for-statement. As was mentioned in the exercise description, we're dealing with the same situation as with subroutine parameters. In this case, we're dealing with the loop variable, which is local to the for-statement. Let's check out the rule for for_init:

method for_init($/) {
    our $?BLOCK;
    our @?BLOCK;

    ## create a new scope here, so that we can
    ## add the loop variable
    ## to this block here, which is convenient.
    $?BLOCK := PAST::Block.new( :blocktype('immediate'),
                                :node($/) );
    @?BLOCK.unshift($?BLOCK);

    my $iter := $( $<identifier> );
    ## set a flag that this identifier is being declared
    $iter.isdecl(1);
    $iter.scope('lexical');
    ## the identifier is initialized with this expression
    $iter.viviself( $( $<expression> ) );

    ## enter the loop variable into the symbol table.
    $?BLOCK.symbol($iter.name(), :scope('lexical'));

    make $iter;
}

So, just as we created a new PAST::Block for the subroutine in the action method for parameters, we create a new PAST::Block for the for-statement in the action method that defines the loop variable. (Guess why we made for-init a subrule, and didn't put in "var <ident&gt = <expression>" in the rule of for-statement). This block is the place to live for the loop variable. The loop variable is declared, initialized using the viviself attribute, and entered into the new block's symbol table. Note that after creating the new PAST::Block object, we put it onto the stack scope.

Now, the action method for the for statement is quite long, so I'll just embed my comments, which makes reading it easier.

method for_statement($/) {
    our $?BLOCK;
    our @?BLOCK;

First, get the result object of the for statement initialization rule; this is the PAST::Var object, representing the declaration and initialization of the loop variable.

    my $init := $( $<for_init> );

Then, create a new node for the loop variable. Yes, another one (besides the one that is currently contained in the PAST::Block). This one is used when the loop variable is updated at the end of the code block (each iteration). The difference with the other one, is that it doesn't have the isdecl flag, and it doesn't have a viviself clause, which would result in extra instructions checking whether the variable is null (and we know it's not, because we initialize the loop variable).

    ## cache the name of the loop variable
    my $itername := $init.name();
    my $iter := PAST::Var.new( :name($itername),
                               :scope('lexical'),
                               :node($/) );

Now, retrieve the PAST::Block node from the scope stack, and push all statement PAST nodes onto it.

    ## the body of the loop consists of the statements written by the user and
    ## the increment instruction of the loop iterator.

    my $body := @?BLOCK.shift();
    $?BLOCK  := @?BLOCK[0];
    for $<statement> {
        $body.push($($_));
    }

If there was a step, we use that value; otherwise, we use assume a default step size of "1".
Negative step sizes won't work, but if you Feel Lucky, you could go ahead and try. It's not that hard, it's just a lot of work, and I'm too lazy for that now.... ehm, I mean, I leave it as the proverbial exercise to the reader.

    my $step;
    if $<step> {
        my $stepsize := $( $<step>[0] );
        $step := PAST::Op.new( $iter, $stepsize, :pirop('add'), :node($/) );
    }
    else { ## default is increment by 1
        $step := PAST::Op.new( $iter,
                               :pirop('inc'),
                               :node($/) );
    }

The incrementing of the loop variable is part of the loop body, so add the incrementing statement to $body.

    $body.push($step);

The loop condition uses the "<=" operator, and compares the loop variable with the maximum value that was specified.

    ## while loop iterator <= end-expression
    my $cond := PAST::Op.new( $iter, $( $<expression> ),
                              :name('infix:<=') );

Now we have the PAST for the loop condition and the loop body, so now create a PAST to represent the (while) loop.

    my $loop := PAST::Op.new( $cond, $body,
                              :pasttype('while'),
                              :node($/) );

Finally, the initialization of the loop variable should go before the loop itself, so create a PAST::Stmts node to do this:

    make PAST::Stmts.new( $init, $loop,
                          :node($/) );
}

Wow, we've done it! This was a good example of how to implement a non-trivial statement type using PAST.

Solutions to the Exercises in Episode 5

2008-04-03T00:54:00.000-07:00

1. In this episode, we changed the action method for the TOP rule; it is now invoked twice, once at the beginning of the parse, once at the end of the parse. The block rule, which defines a block to be a series of statements, represents a new scope. This rule is used in for instance if-statement (the then-part and else-part), while-statement (the loop body) and others. Update the parse action for block so it is invoked twice; once before parsing the statements, during which a new PAST::Block is created and stored onto the scope stack, and once after parsing the statements, during which this PAST node is set as the result object. Make sure $?BLOCK is always pointing to the current block. In order to do this exercise correctly, you should understand well what the shift and unshift methods do, and why we didn't implement methods to push and pop, which are more appropriate words in the context of a (scope) stack.

Keeping the Current block up to date
Sometimes we need to access the current block's symbol table. In order to be able to do so, we need a reference to the "current block". We do this by declaring a package variable called "$?BLOCK", declared with "our" (as opposed with "my"). This variable will always point to the "current" block. As blocks can nest, we use a "stack", on which newly created blocks are stored.
Whenever a new block is created, we assign this to $?BLOCK, and store it onto the stack, so that the next time a new block is created, the "old" current block isn't lost. Whenever a scope is closed, we pop off the current block from the stack, and restore the previous "current" block.

Why unshift/shift and not push/pop?
When we're talking about stacks, it would seem logical to talk about stack operations such as "push" and "pop". Instead, we use the operations "unshift" and "shift". If you're not a Perl programmer (such as myself), these names might not make sense. However, it's pretty easy. Instead of pushing a new object onto the "top" of the stack, you unshift objects onto this stack. Just see it as an old school bus, with only one entrance (at the front of the bus). Pushing a new person means taking the first free seat when entering, while unshifting a new person means everybody moves (shifts) one place to the back, so the new person can sit in the front seat. You might think this is not as efficient (more stuff is moved around), but that's not really true (actually: I guess (and certainly hope) the shift and unshift operations are implemented more effectively than the bus metaphor; I don't know how it is implemented).

So why unshift/shift, and not push/pop? When restoring the previous "current block", we need to know exactly where it is (what position). It would be nice to be able to always refer to the "first passenger on the bus", instead of the last person. We know how to reference the first passenger (it's on seat no. 0 (it was designed by an IT guy)); we don't really know what is the seat no. of the last person: s/he might sit in the middle, or at the back.

I hope it's clear what I mean here... otherwise, have a look at the code, and try to figure out what's happening:

method block($/, $key) {  
  our $?BLOCK;
  our @?BLOCK;
  if $key eq 'open' {
        $?BLOCK := PAST::Block.new(
                    :blocktype('immediate'), 
                      :node($/) );
       @?BLOCK.unshift($?BLOCK);
    }
    else {
        my $past := @?BLOCK.shift();
        $?BLOCK  := @?BLOCK[0];

        for $<statement> {
            $past.push( $( $_ ) );
        }
        make $past;
    }
}

Solutions to the Exercises in Episode 4

2008-04-01T01:49:00.000-07:00

These are the solutions to the exercises in Episode 4 of the Parrot Compiler Tools tutorial.

1. We showed how the if-statement was implemented. The while-statement and try-statement are very similar. Implement these. Check out pdd26 to see what PAST::Op nodes you should create.

The while-statement is straightforward:

method while_statement($/) {
    my $cond := $( $<expression> );
    my $body := $( $<block> );
    make PAST::Op.new( $cond, $body,
                       :pasttype('while'),
                       :node($/) );
}

The try-statement is a bit more complex. Here are the grammar rules and action methods.

rule try_statement {
    'try' $<try>=<block>
    'catch' <exception>
    $<catch>=<block>
   'end'
    {*}
}

rule exception {
    <identifier>
    {*}
}

method try_statement($/) {
    ## get the try block
    my $try := $( $<try> );

    ## create a new PAST::Stmts node for
    ## the catch block; note that no
    ## PAST::Block is created, as this
    ## currently has problems with the
    ## exception object. For now this will
    ## do.
    my $catch := PAST::Stmts.new( :node($/) );
    $catch.push( $( $<catch> ) );

    ## get the exception identifier;
    ## set a declaration flag, the scope,
    ## and clear the viviself attribute.
    my $exc := $( $<exception> );
    $exc.isdecl(1);
    $exc.scope('lexical');
    $exc.viviself(0);

    ## generate instruction to retrieve
    ## the exception objct (and the
    ## exception message, that is passed
    ## automatically in PIR, this is stored
    ## into $S0 (but not used).
    my $pir := "    .get_results (%r, $S0)\n"
             ~ "    store_lex '" ~ $exc.name()
             ~ "', %r";

    $catch.unshift( PAST::Op.new(
                      :inline($pir),
                      :node($/) ) );

    ## do the declaration of the exception
    ## object as a lexical here:
    $catch.unshift( $exc );

    make PAST::Op.new( $try, $catch,
                       :pasttype('try'),
                       :node($/) );
}

method exception($/) {
    our $?BLOCK;
    my $past := $( $<identifier> );
    $?BLOCK.symbol( $past.name(), :scope('lexical') );
    make $past;
}

Instead of putting "identifier" after the "catch" keyword, we made it a separate rule, with its own action method. This allows us to insert the identifier into the symbol table of the current block (the try-block), before the catch block is parsed.

First the PAST node for the try block is retrieved. Then, the catch block is retrieved, and stored into a PAST::Stmts node. This is needed, so that we can make sure that the instructions that retrieve the exception object come first in the exception handler.

Then, we retrieve the PAST node for the exception identifier. We're setting its scope, a flag telling the PAST compiler this is a declaration, and we clear the viviself attribute. The viviself attribute is discussed in a later episode; if you didn't read that yet, just keep in mind the viviself attribute (if set) will make sure all declared variables are initialized. We must clear this attribute here, to make sure that this exception object is not initialized, because that will be done by the instruction that retrieves the thrown exception object, discussed next.

In PIR, we can use the .get_results directive to retrieve a thrown exception. You could also generate the get_results instruction (note the missing dot), but this is much easier. Currently, in PIR, when retrieving the exception object, you must always specify both a variable (or register) for the exception object, and a string variable (or register) to store the exception message. The exception message is actually stored within the exception object. We use $S0 to store the exception message, and we'll ignore it after that. Just remember for now that if you want to retrieve the exception object, you must also specify a place to store the exception message.
There is no special PAST node to generate these instructions, so we use a so-called inline PAST::Op node. We store the instructions to be generated into a string and store that in the inline attribute of a PAST::Op node. Once created, this node is unshifted onto the PAST::Stmts node representing the exception handler. After that, the declaration is stored in that PAST::Stmts node, so that this declaration comes first.

Finally, we have the block representing the try block, and a PAST::Stmts node representing the exception handler. Both are used to create a PAST::Op node whose pasttype is set to the built-in "try" type.

2. Start Squaak in interactive mode, and specify the target option to show the generated PIR instructions. Check out what instructions and labels are generated, and see if you can recognize which instructions make up the conditional expression, which represent the "then" block, and which represent the "else" block (if any).

> if 1 then else end

.namespace
.sub "_block16"
new $P18, "Integer"
assign $P18, 1

## this is the condition:
if $P18, if_17

## this is invoking the else-block:
get_global $P21, "_block19"
newclosure $P21, $P21
$P20 = $P21()
set $P18, $P20
goto if_17_end

## this is invoking the then-block:
if_17:
get_global $P24, "_block22"
newclosure $P24, $P24
$P23 = $P24()
set $P18, $P23
if_17_end:
.return ($P18)
.end

.namespace
.sub "_block22" :outer("_block16")
.return ()
.end

.namespace
.sub "_block19" :outer("_block16")
.return ()
.end

Solutions to the Exercises in Episode 3

2008-03-31T01:18:00.000-07:00

By now, you may have finished the PCT tutorial. If you felt too lazy to do the exercises or if you want to see what solution I had in mind, here are the solutions to the exercises in Episode 3 (Episode 1's exercise was discussed at the end of Episode 2, and the latter didn't have any coding assignments).

1. Rename the names of the action methods according to the name changes we made on the grammar rules. So, "integer" becomes "integer_constant", "value" becomes "expression", and so on.

I assume you don't need any help with this.

2. Look at the grammar rule for statement. A statement currently consists of an assignment. Implement the action method "statement" to retrieve the result object of this assignment and set it as statement's result object using the special make function. Do the same for rule primary.

method statement($/) {
    make $( $<assignment> );
}

Note that at this point, the rule statement doesn't define different #= keys for each type of statement, so we don't declare a parameter $key. This will be changed later.

method primary($/) {
    make $( $<identifier> );
}

3. Write the action method for the rule identifier. As a result object of this "match", a new PAST::Var node should be set, taking as name a string representation of the match object ($/). For now, you can set the scope to 'package'. See "pdd26: ast" for details on PAST::Var nodes.

method identifier($/) {
    make PAST::Var.new( :name(~$/),
                        :scope('package'),
                        :node($/) );
}

4. Write the action method for assignment. Retrieve the result objects for "primary" and for "expression", and create a PAST::Op node that binds the expression to the primary. (Check out pdd26 for PAST::Op node types, and find out how you do such a binding).

method assignment($/) {
    my $lhs := $( $<primary> );
    my $rhs := $( $<expression> );
    $lhs.lvalue(1);
    make PAST::Op.new( $lhs, $rhs,
                       :pasttype('bind'),
                       :node($/) );
}

Note that we set the lvalue flag on $lhs. See PDD26 for details on this flag.

5. Run your compiler on a script or in interactive mode. Use the target option to see what PIR is being generated on the input "x = 42".

.namespace
.sub "_block10"
    new $P11, "Integer"
    assign $P11, 42
    set_global "x", $P11
    .return ($P11)
.end

The first two lines of code in the sub create an object to store the number 42, the third line stores this number as "x". The PAST compiler will always generate an instruction to return the result of the last statement, in this case $P11.

Episode 9: Wrap up and Conclusion

2008-03-23T11:59:00.000-07:00

Welcome to the final Episode of the Parrot Compiler Tools Tutorial! Let's review the previous episodes, and summarize this tutorial.

Review
In Episode 1, we introduced the Parrot Compiler Tools (PCT), gave a high-level feature overview of Squaak, the case study language that we are implementing in this tutorial, and we generated a language shell that we use as a foundation to implement Squaak.

Episode 2 discussed the general structure of PCT-based compilers. After this, we described each of the four default compilation stages: parse phase, parse tree to PAST, PAST to POST and POST to PIR. We also added a command line banner and command line prompt to the interactive language shell.

In Episode 3, we introduced the full grammar of the Squaak language. After this, we started implementing the first bits, after which we were able to generate code for (simple) assignments.

In Episode 4 we discussed the construction of Parrot Abstract Syntax Tree nodes in more detail, after which we implemented the if-statement and throw-statement.

Episode 5 focused on variable declarations and variable scope. We implemented the necessary infrastructure to handle global and local variables correctly. In Episode 6 we continued the discussion of scope, but now in the context of subroutines. After this we implemented subroutine invocation.

Episode 7 extended our grammar to handle complex expressions that allows us to use arithmetic and other operators. We discussed how to use PCT's built-in support for handling operator precedence.

In the previous episode, Episode 8, we discussed the grammar and action methods for handling the aggregate data types of Squaak: arrays and hashes. We also touched on the topic of argument passing by reference and by value.

If you followed the tutorial and did the exercises, your implementation should be complete. Although a lot of the implementation was discussed, some parts were left as the proverbial exercise to the reader. This is to stimulate you to get your hands dirty and figure out things for yourself, while the text contained enough hints (in my opinion) to solve the given problems. Sure enough, this approach requires you to spend more time and think for yourself, but I think you're reading all this stuff to learn something. The extra time spent is well worth it, in my opinion.

Now it's time to see what we can do with this language. Squaak is more than just the average calculator example, which is often provided in beginner's discussions on parsers; it's a complete programming language.

What's Next?
This is the last episode of the Parrot Compiler Tools tutorial. We showed how we implemented a complete language for the Parrot virtual machine in only a few hundred lines of source code. Surely, this must be the proof that the PCT really is an effective toolkit for implementing languages. At the moment of writing, the PCT still lacks efficient support for certain language constructs. Therefore, we focused on the parts that are easy to build with the PCT. Once the PCT is feature complete, there's bound to be another tutorial on advanced features. Think of object-oriented programming, closures, coroutines, and advanced control-flow such as return statements. Most of them can be done already, but are too complex for this tutorial's level.

The Game of Life
You might have noticed that Squaak looks a bit like Lua, although it does differ in some points. This is not entirely accidental. In the distribution of the Lua source code, there's an example called "life.lua", which implements Conway's "Game of Life". This is a nice demonstration program, and it's easy to port it to Squaak. Its implementation is shown below. Run it, and enjoy!

## John Conway's Game of Life
## Implementation based on life.lua, found in Lua's distribution.
##
var width          = 40    # width of "board"
var height         = 20    # height of "board"
var generation     = 1     # generation couner
var numgenerations = 50    # how often should we evolve?

## initialize board to all zeroes
sub initboard(board)
    for var y = 0, height do
        for var x = 0, width do
            board[y][x] = 0
        end
    end
end

## spawn new life in board, at position (left, top),
## the life data is stored in shapedata, and shape width and
## height are specified.
sub spawn(board, left, top, shapew, shapeh, shapedata)
    for var y = 0, shapeh - 1 do
        for var x = 0, shapew - 1 do
            board[top + y][left + x] = shapedata[y * shapew + x]
        end
    end
end

## calculate the next generation.
sub evolve(thisgen, nextgen)
    var ym1 = height - 1
    var y   = height
    var yp1 = 1
    var yi  = height

    while yi > 0 do
        var xm1 = width-1
        var x   = width
        var xp1 = 1
        var xi  = width

        while xi > 0 do

            var sum = thisgen[ym1][xm1]
                    + thisgen[ym1][x]
                    + thisgen[ym1][xp1]
                    + thisgen[y][xm1]
                    + thisgen[y][xp1]
                    + thisgen[yp1][xm1]
                    + thisgen[yp1][x]
                    + thisgen[yp1][xp1]

            nextgen[y][x] = sum==2 and thisgen[y][x] or sum==3

            xm1 = x
            x   = xp1
            xp1 = xp1 + 1
            xi  = xi - 1
        end

        ym1 = y
        y   = yp1
        yp1 = yp1 + 1
        yi  = yi - 1

    end
end

## display thisgen to stdout.
sub display(thisgen)
    var line = ""
    for var y = 0, height do
        for var x = 0, width do
            if thisgen[y][x] == 0 then
                line = line .. "-"
            else
                line = line .. "O"
            end

        end
        line = line .. "\n"
    end
    print(line, "\nLife - generation: ", generation)
end

## main program
sub main()
    var heart   = [1,0,1,1,0,1,1,1,1]
    var glider  = [0,0,1,1,0,1,0,1,1]
    var explode = [0,1,0,1,1,1,1,0,1,0,1,0]

    var thisgen = []
    initboard(thisgen)

    var nextgen = []
    initboard(nextgen)

    spawn(thisgen,3,5,3,3,heart)
    spawn(thisgen,5,4,3,3,glider)
    spawn(thisgen,25,10,3,4,explode)

    while generation <= numgenerations do
        evolve(thisgen, nextgen)
        display(thisgen)
        generation = generation + 1

        ## prevent switching nextgen and thisgen around,
        ## just call evolve with arguments switched.
        evolve(nextgen, thisgen)
        display(nextgen)
        generation = generation + 1

    end
end

## start here.
main()

Note the use of a subroutine "print". Check out the file src/builtins/say.pir, and rename the sub "say" (which was generated by the language shell creation script) to "print".

Exercises
Squaak was designed to be a simple language, offering enough features to get some work done, but at the same time keeping it simple. Of course, after reading this tutorial, You are an expert too ;-) If you feel like adding more features, here are some suggestions.

Implement prefix and postfix increment/decrement operators, allowing you to write "generation++" instead of "generation = generation + 1".
Implement augmenting assign operators, such as "+=" and friends.
Extend the grammar to allow multiple variable declarations in one statement, allowing you to write "var x = 1, y, z =3". Of course, the initialization part should still be optional. How do you make sure that the identifier and initialization expression are kept together?
Implement a mechanism (such as an "import" statement) to include or load another Squaak file, so Squaak programs can be split into multiple files. The PCT does not have any support for this, so you'll need to write a bit of PIR to do this.
Improve the for-statement, to allow for a negative step. Note that the loop condition becomes more complex when doing so.

Note that these are suggestions, and I did not implement them myself, so I won't have a solution for you at the end.

Final words and Acknowledgments
By now, you should have got a good impression of the PCT and you should be able to work on other languages targeting Parrot. Currently, work has been done on ECMAScript, Python, Ruby and of course Perl 6. Most of them are not complete yet (hint, hint).

I hope you enjoyed reading this tutorial and learned enough to feel confident about working on other (existing) languages targeting Parrot. The Perl 6 implementation can still use more contributors!

Many thanks to all who read this tutorial and provided me with hints, tips and feedback! Thank You for reading this!

License
The source code in this tutorial has been released by the author into the public domain. Where this is not possible by law, the author grants license to use this file for any reason without any rights reserved, and with no warranty express or implied or fitness for a particular purpose.