This week on Perl 6, week ending 2003-08-17

Picture, if you will a sunny garden, unaffected by power cuts, floods, plagues of frog or any of the other troubles that assail us in this modern world. Picture, if you will, your summarizer, sat in this garden with a laptop on his knee, cursing the inability of LCD display manufacturers to make displays that are legible in sunlight. Picture your summarizer returning to the comfortable chair in the shade of his book room casting around for a witty and original way to open another Perl 6 summary. Picture him giving up and starting to type. Here’s what he writes:

We start, as usual, with the the internals list.

Tail call optimization

Leo Tötsch has started to work on getting IMCC to detect tail calls and optimize them to either a simple jump or an invoke. If you’re not sure what tail call optimization is I can recommend Dan’s ``What the heck is a tail call?” article on the subject. – What the heck?

Leo’s QUERIES from last week

Last week, Leo bundled up a bunch of outstanding questions for Dan, and Dan answered them. Benjamin Goldberg queried Dan’s answer about find_method, which, if I’m reading things correctly is currently implemented in the interpreter. Benjamin argued (convincingly I thought) that, although the method hashes needed to be stored in the interpreter structure, find_method should be implemented on default.pmc, allowing for different classes/languages to override its behaviour.

Why ~ for xor?

Michal Wallace wanted to know why ~ maps to both unary bitwise-not and binary bitwise-xor in IMCC; he expected xor to be ^ and ^^. Leo explained that it was, at one point at least, the way Perl 6 did it but that he’d stopped keeping up with the developments in perl6-language. He noted that, if the Perl 6 operator had been settled, then IMCC should use that. A quick skim of my copy of Perl 6 Essentials tells me that Perl 6 now uses +&, +| and +^ for bitwise and/or/xor, with ~&, ~|, ~^ for stringwise and/or/xor. – My review of Perl 6 Essentials

Raising Hell

Michal Wallace’s Py-Pirate project continues to exercise the edges of Parrot as he implements more and more of Python’s semantics. This time he needed to know about raising (and catching) exceptions. In particular he wanted to be able to catch an exception when find_lex failed to find an appropriately named variable. (Currently, a find_lex failure doesn’t raise an exception, it just kills Parrot). Jos Visser told him that there were plans to have find_lex throw a real, catchable exception, or maybe just return undef. See last week’s summary for a pointer to that discussion.

Pirate status and help with instances

Michal Wallace announced that he had just finished an all night coding spree and that Py-pirate could now handle:

  • functions (closures, recursion, etc)
  • Global variables
  • tuples (but they turn into lists)
  • dictionaries (create, setitem, getitem, print)
  • list comprehensions
  • raise (strings only)
  • try...except (partial)
  • try...finally
  • assert

(At this point, I think we should all pause for moment of wild applause).

However, he was having a few problems with instantiating objects of a class. (For those who don’t know, Python instances are created by calling the Class as if it were a function). Leo Tötsch noted that almost nothing would work, since Parrot’s classes and objects weren’t actually finished yet. He agreed with others in the thread who reckoned that Python classes could be made to work by subclassing the standard class.pmc to allow it to respond to an invoke by by creating a new instance. Easy! Michal muttered something about faking classes with closures but I don’t think he went through with it.

Packfile fun

So long, it’s been good to know you.

Approaching m4

Leon Brocard, Sean O’Rourke and James Michael DuPont looked on in awe as Bernhard Schmalhofer announced that he’d been working on implementing m4 in Parrot. According to Sean, the ``implications are staggering… Sure, plenty of compilers can bootstrap themselves, but how many can generate their own configure scripts via autoconf? With p4rrot, we may live to see this dream.”

One does worry about Sean’s dream life.

Call and return conventions

TOGoS has been thinking about the workings of the Parrot calling conventions. He wondered if there was a case for making calling and returning look exactly the same, allowing for cunning stunts with fake continuations in P1. Luke Palmer really liked the idea. Leo seemed to think it was a good idea too. There has been no word from Dan yet.

Packfile and EXEC

Leo Tötsch has started to extend the packfile functions to handle multiple code segments and has been running into problems with EXEC – the tool that uses the JIT to generate a native executable from Parrot assembly. Daniel Grunblatt checked in a ‘temporary’ fix, which at least solved Leo’s immediate problem.

Parrot 0.1.0 – what’s left?

Steve Fink thought, given the ‘insane amount of work’ on Parrot recently, that it was approaching time to cut another release. He asked if there was anything else coming up that people would like to see included in the release, and whether we had enough to call the next release 0.1.0. Luke Palmer really wanted to see objects finished, but wasn’t sure how much would that would entail. Leo thought that the Parrot Calling Conventions (and more particularly the return convention) support needed fixing, and noted that PackFile is currently in a state of flux. Both of them thought 0.1.0 would be the right version number though.

set vs. assign continues to add vs add!

TOGoS wasn’t keen on the variable behaviour of add depending on whether its target was a PMC, or an integer/number register. Brent Dax thought that TOGoS needed to train his expectations and went on to explain why.

For reasons that I can’t quite follow, this discussion morphed into a polite argument between Dan and Leo about the wisdom of having all those keyed opcodes.

Benjamin Goldberg pointed out that, since TOGoS’s desired ‘set’ semantics could easily mocked up with an assign operator (but not vice versa), then maybe IMCC could handle mocking it up automatically.

Serializing functions

Michal Wallace wondered if it is possible to serialize a Parrot function, or (slightly more tricky) if you could serialize a generator and its state. Answer: Yes, it’s almost done (well, the function part anyway; Leo didn’t’ mention the generator thing).

I’m not sure if the support for this was fixed up in the packfile changes that Leo checked in a couple of hours after his answer.


Arthur Bergman popped over from ponie-dev to ask about a problem he’d been having with his parrot embedded miniperl. Apparently, if a caller closes STDERR, the program produces no output on STDOUT either. Leo found where the problem was happening – Parrot was trying to open STDERR, failing, and dying with an error message. To STDERR. Jürgen Bömmels, the ParrotIO maintainer, outlined a few possible fixes.

Calling Parrot from C

Luke Palmer asked about calling a parrot sub from C and getting the return value. Leo gave a terse answer that covered the bases and pointed at classes/Eval.pmc for an implementation of something very like the general case of calling parrot subs from C.

There’s no undef!

Michal Wallace discovered that there seems to be no op to remove a variable from a lexical pad. Leo patched the scratchpad PMC so that you can now do:

    peek_pad Pn
    delete Pn["foo"]

to delete variable names.

Pirate 0.01 ALPHA!

Michal Wallace announced the version 0.01 alpha of Pirate which he described as ``(almost) everything I can do for Python without jumping into C”. Which turns out to be an awful lot of stuff.

I’ve just looked back through my summary archive and, as near as I can tell, Michal’s gone from thinking about doing this to having most of the Python syntax working in just under 3 weeks, which is really rather scary when you think about it. Well done Michal.

Timely destruction: An efficient, complete solution

Right at the end of the week, Luke Palmer posted another attempt to come up with a neat solution to the timely destruction problem. I’m guessing we’ll see it discussed in next week’s summary.

POW (Parrot on Win32) available

A while ago now, Jonathan Worthington offered to start making regular binary builds of Parrot for those who use Win32 but who can’t compile Parrot on it. This week he announced that he’s done it. Thanks Jonathan. – The POW site

Implementing Nickle

Simon Cozens pointed the list at the nickle programming language and wondered if it might be a suitable language to implement on Parrot. – The Nickle site

Meanwhile, in perl6-language

Traffic was light. Very light.

Apocalypses and Exegeses

Alberto Manuel Brandão Simões, noting that the Apocalypses and Exegeses were subject to later modification, wondered if anyone had any idea when we’d have a freeze on the syntax and features for Perl 6. The obvious joke – ``Sometime after Perl 5’s syntax and features freeze” – was cracked. The consensus was that the syntax is currently ‘slushy’, and will probably firm up in the next 6-12 months. There was also some discussion of Perl 6 Essentials, and Nicholas Clark pointed us all at a new book that Alan Burlison had found.

Acknowledgements, Announcements and Apologies

If anyone’s following the ‘moving to the North East’ saga, last week’s offer fell through, but that was actually a good thing as we’re now buying my daughter’s Tyneside flat instead, which does rather take some of the ‘got to get everything sold by mid September’ pressure off and replaces it with ‘How on earth are we going to fit the contents of a 4 bedroomed house into a two bedroomed flat?’ pressure.

In case you hadn’t already spotted that I was impressed, much kudos goes to Michal Wallace for his sterling work on Pirate. Three weeks from concept to having a huge chunk of the language implemented is just amazing.

Check out for more of my writing.

As ever, if you’ve appreciated this summary, please consider one or more of the following options:



Something wrong with this article? Help us out by opening an issue or pull request on GitHub