This Week on Perl 6 (8 - 14 Jul 2002)

Perl 6 summary for week ending 20020714

Well, what a week it's been, eh, sportsfans? Without further ado, here's a rundown of all the excitement in the Perl 6 development camps.

Still waiting for Exegesis 5?

The week before last saw a couple of fantastic postings on Perlmonks dealing with the fun stuff in Apocalypse 5. I'm sorry I missed them last week. Damian is still beavering away on the Exegesis, but these (shall I call them Apocrypha?) are worth reading.

Is Parrot a second system?

John Porter worried about the second-system effect, and about whether the movement to implement a bunch of 'foreign' VM ops on Parrot was just going to add bloat and inefficiency. Dan assured him that ``these 'add-on' bytecode interpreters don't get any special consideration in the core.'' John was reassured.

I think it was decided that Parrot is a second system, but that we're working it to avoid the classic problems associated with it.

Don't mix labels and comments

Simon Glover had a problem with

    A:              # prints "a"
        print "a"

which kills the assembler because of the presence of the comment. Tom Hughes posted a patch to fix it, and Brian Wheeler pointed out that the patch means you can't do print "#", which would be bad. Tom reckons he fixed that with his second patch. Tom's initial fix. And the second.

Perl 6 grammar, take 5

Sean O'Rourke is my hero. He's still beavering away on writing a Perl 6 grammar. The latest incarnation is apparently, ``Turing-complete, if you have a Parrot engine and a bit of spare time.'' The grammar is still incomplete (of course), and someone pointed out that it had a problem with code like { some_function_returning_a_hash() }. Should it give a closure? Or a hash ref. Larry hasn't commented so far.

Sean comments: ``The fact that I've been able to whip this up in a couple thousand lines of code is a remarkable testament to Parrot's maturity, and to the wealth of tools available in Perl 5. In particular, without The Damian's Parse::RecDescent, Melvin Smith's IMCC, and Sarathy's Data::Dumper, it never would have been possible.''

Quote of the thread: ``What, this actually runs? Oh, my.'' -- Dan Sugalski

So, What Is IMCC Then?

I asked, they answered. Apparently, reading TFM would have been a good place to start, though Melvin Smith didn't put it quite so bluntly when he told me. Essentially, the IMCC is the Parrot intermediate language compiler. It's a bit like an assembler but sits at a slightly higher level and worries about the painful things like ``register allocation, low level optimisation, and machine code generation.'' And everyone gets to share that wealth -- Perl6, Ruby, Python, whatever -- they all need the same facilities that IMCC provides.

The idea is that, instead of worrying about registers, you just provide a string of temporaries or named locals, so you can write:

    $I1 = 1
    $I2 = 2
    $I3 = $I1 + $I2
    $I5 = $I3 + 5

And IMCC will notice that it only needs to use two registers when it turns that into:

    set I0, 1
    set I1, 2
    add I0, I0, I1
    add I0, I0, 5

Melvin finishes by saying: `` If people don't get anything else, they should get this. Implementing a compiler will be twice as easy if they target the IR instead of raw Parrot. At a minimum, they implement their parser, generate an AST, and walk the tree, emitting intermediate expressions and directives.''

Leon Brocard, who I am constitutionally required to namecheck in every Perl 6 summary, tells me: ``IMCC is the coolest thing. ... Please don't quote me verbatim.'' Tee hee.

The fine manual is at languages/imcc/README in the Parrot source tree.

Vtables and Multimethod Dispatch

This continued from last week. For some reason this ended up with a discussion of Pythagoras' Theorem and Manhattan Distance (this was to do with the idea of dispatch based on distance in type space ... .)

John Porter worried about the cost of generating full MM dispatch tables, quoting some scary numbers. Dan reckoned that the numbers weren't that scary, and that the problem was limited quite neatly.

Quote of the thread: ``I'm not sure I want an algorithm that drives on the sidewalks, runs red lights, and chases pedestrians ... .'' -- Dan Sugalski (again) is a good 'root' to start at. Quote of the thread, in context.

Can I put out a plea for someone, once the dust has settled, to summarise the state of multidispatch?

Building Support for Non-Native Bytecode

Dan mapped out what would be needed to implement a non-native VM. I think he just wants to play Zork using parrot, but I'd never actually say that. He also said he'd have the specs for dynamic opcode and PMC loading out within 24 hours, but I think events may have intervened.

Mutable vs. Immutable Strings

Clark C. Evans reckoned that we'd need both strings and buffers and argued that all strings should start as mutable, but that it should be possible to 'freeze' them. He also pointed out that there should be no corresponding 'thaw' operation. He wondered too whether these semantics might be useful for more than just strings. Florian Haeglsperger wondered whether Copy on Write didn't solve the problem at a stroke, to which the answer appears to be 'not really.' Dan thinks that 'read-onlyness' should probably hang off PMCs rather than strings and buffers. Dan also commented that we need to nail down some semantics about when things can and can't be modified.

The discussion slowly morphed into a discussion of types in Perl and other languages. Melvin Smith noted that ``we've built this register based VM upon which Perl will probably be the most non-optimised language. Things like exposing your lexical pads, eval, etc., blow optimisation out of the water,'' but reckoned that Perl itself would probably still see a massive speed-up.

Ashley Winters got scary. A paragraph that begins, ``Whenever the compiler runs across an eval, take a continuation from within the compiler,'' is always going to be worrying. Actually, he proposed it as a topic for a CS master's thesis, and Dan pointed out that one Damian Conway is looking for students.

Quote of the thread: A tie between Ashley's paragraph opener above and ``[Parrot] will have reflection, introspection, and Deep Meditative Capabilities.'' -- Who else, Dan Sugalski (re)start here.

Adding the System Stack to the Rootset.

One of the weird things about a system that can do continuations is that stack frames need to come out of managed memory, you can't just use the C stack. And if you *don't* manage stack frames using garbage collection, then you end up with memory leaks because the stack frames don't get released; which is where we stood.

Dan is in the process of making sure that system stack frames get properly garbage collected. Mike Lambert also stepped up and did some/most of the implementation. Mike's patch.

Making Keyed Aggregates Really Work.

Melvin Smith put out a call for someone to do an audit of the keyed aggregate handling code and find out which methods are missing, which ones aren't handled by the assembler and generally to fix them. Sean (Her)O'Rourke has apparently done the deed.

Parrot: Copying Arrays

Alberto Simões wondered about copying and cloning arrays and other aggregates. How deeply should one go when making a copy as opposed to just taking a reference? This one is still awaiting an answer.

Coders: Add Doco

The internals list came close to a flame war over this one. John Porter opened with the somewhat incendiary, ``I have to say that I am extremely disappointed at the paucity of internal documentation,'' and went on to make some good points, but in a tone that rather annoyed several people.

Productive stuff that came out of this, and the subsequent 'Parrot contribution' thread include:

  • FAQ writing should be a collaborative effort. The questions that an experienced Parrot head has, or thinks are important, are probably not the questions that a newbie would ask.
    So, if you have a question that you think belongs in the FAQ, then send a message to the list with a subject line of 'PARROT QUESTION' and we'll try and produce some sensible answers and add them to the FAQ.
  • The Parrot IRC channel is a good place for some stuff but has no 'journal of record.' Something like's lovely 'scribot' bot could prove useful. (I'm deliberately not putting pointers to the IRC channel. If you need to know, then read the thread.)
  • Why questions, and their answers are often really important.
  • We really should be maintaining the .dev files associated with each source file, as mentioned in PDD7.
  • Dan tries to be on IRC regularly from 1300-1700EST Wednesday. ``While it's no substitute for e-mail, and not as good a realtime communication method as face to face communication, it's better than no realtime communication at all.''

In the end, I think we ended up generating more light than heat, but it was touch and go for a while ... .


Sadly, the first PARROT QUESTION post didn't contain any actual questions. Ashley Winters pointed out that 'test_main.c' is a rather weird place to find parrot's main loop and wondered why parrot.c is empty.

His follow-up contained the actual questions, most of which were answered in the following thread, which is still ongoing.

Tom Hughes told us he was trying to make sense of the current status of keyed access at all levels, from assembler through the ops to the vtables and is getting more confused the more he looks; which can't be good. Melvin Smith agreed that things were confusing, but thought that things might get a little less confusing when he'd committed Sean's patches. Discussion is ongoing. Ashley's background post. Ashley's questions Tom Hughes on keyed access

More Docs

Stephen Rawls submitted, an overview of the regular expression code. Brent Dax added some clarification.

Alberto Simões unveiled a pile of documentation for the Array, PerlArray and PerlHash PMCs, earning himself a few Hero Points from me.

Type Morphing

I'm not entirely sure I understood this thread. Sean O'Rourke submitted some patches to fix Parrot's PMC type morphing. Mike Lambert pointed at some ambiguities and then Sean showed some code that seems rather counter intuitive to do with type morphing and comparisons. He also provided a test file that shows some places where Perl 5 and Parrot seem to disagree on semantics.

Glossary Requests

Mike Litherland made some suggestions about what should go in the glossary. Patches were welcomed, and Dan added some terms to the glossary, which is visible at

Meanwhile, in Perl6-language

The game of 'find a good description of continuations' rumbled on for a bit. I liked Mike Lambert's description involving a traveler in a maze (that's why Dan wants a Z-machine interpreter running on Parrot. Continuations are the 'maze of little twisty passages all similar').

Anyway, Dan also posted a splendidly clear and lucid explanation of continuations. (Oh, frabjous day! Calloo! Callay!) Peter Scott wondered about serializing continuations, which is a tough problem because some state really can't be serialized (filehandles for instance), which lead Ted Zlatonov to suggest FREEZE {...} and THAW {...} blocks. Mike's 'maze' analogy. Dan's ``Continuations are just the stack, you know?'' version.

What's MY.line

Chip Salzenburg asked some hardish questions about MY, %MY and the difference between them. Piers (continuations everywhere) Cawley, proposed $a_continuation.the_pad, which should probably be $a_continuation.MY on further reflection, which Dan seemed to think wasn't utterly insane.

It was also proposed that things like

    [localhost:~] $ perl
    my $foo = 12;
    print $foo;
    my $foo = 'ho';
    print $foo;
    12ho[localhost:~] $

which is legal (with -w a warning) in Perl 5 should be illegal in perl 6. This was left as Larry's call.

Quote of the thread: 'And side effects like ``I call you, you modify me invisibly ... '' seems more like taking dangerous drugs than programming.' -- Melvin Smith

On seeing the quote of the thread, Richard (madman) Clamp popped up to point out that, with the aid of Devel::LexAlias, you could already do that in Perl 5. Which is nice. Thread starts here. Pretty much all worthwhile. Quote in context Richard Clamp's bombshell

In Brief -- Mark M. Adkins announced a perl script that hunts down all the POD files in the Parrot directory tree and uses that to generate an HTML tree in a new subdirectory. It looks rather handy. -- Dan pointed us at an explanation of CPU caches

Robert Spier pointed everyone at, specifically the Development Resources.

Sean O'Rourke proposed ripping a bunch of set_* ops out of core.ops now that we've got 'proper' keyed access in the assembler. Dan concurred. Tanton Gibbs sent a patch that adds documentation and a .dev file for byteorder.c

Nicholas Clark is trying to eliminate compiler warnings. Steve Purkis has a patch to add usleep(int) and sleep(int) to the Linux version of Parrot. Dan likes the idea, but the patch won't go in until it can be made to work on Win32 as well. Luke Palmer has a vim highlighting file for Perl 6.

The return of ``Who's Who in Perl 6''

This week, Allison Randal answered the new standard ``5Ws questionnaire''

Who are you?
I'm on the IT staff at the University of Portland. In my spare time I enjoy working on Perl 6. In my spare-spare time I like to swing in a hammock and read and ponder the ineffability of 42.
What do you do for/with Perl 6?
I dream in Perl 6 ... ;)

On the Perl 6 design team I'm the other linguist, or Damian's clone, or the assistant cat-herder, or sometimes the Devil's Advocate. It depends on the day, really.

Where are you coming from?
Perl 6 will be an incredible jump in power and flexibility. But it's also a lot easier to use. I think that fact is often missed. People see a flurry of changes, but they can't see the forest for the trees. It's not just about making the hard things more possible, it's about making the easy things easier. That's the message I want to carry.
When do you think Perl 6 will be released?
February 17, 2004 at 13:42 GMT. ;) Okay, no. :) But the current estimates of 12-18 months sound pretty reasonable, especially with the progress we've seen in Parrot.
Why are you doing this?
Life's too short to settle for weak coffee.

No, really, for the most selfish reason imaginable: I want to use Perl 6. Anything I can do to make it a better language or to help it reach production faster is well worth the effort.

And it's incredibly fun.

You have five words. Describe yourself.
Extreme Geekiness in Unusual Packaging.
Do you have anything to declare?
Perl rules!


Thanks to the denizens of #perl and #parrot for their, ahem, 'mad proofreading skeelz.' To Melvin Smith and Leon Brocard for their explanations of IMCC.

This summary was brought to you with the assistance of GNER tea, and the music of Waterson:Carthy and Gillian Welch.

Once again, if you liked it, then give money to YAS, if you didn't like it, well, then you can still give them money; maybe they'll use it to hire a better writer. Or maybe you could write a competing summary.

Visit the home of the Perl programming language:

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en