This week on Perl 6, week ending 2003-11-02

It's Monday morning, the croissants have been baked, the focaccia is glistening with all the extra virgin olive oil I poured on it as it left the oven and, in the airing cupboard, a raisin borodinsky slouches towards full proof (thought at the rate it's currently rising it'll probably be Tuesday before I can bake it off), what better time could there be to pause and write a summary?

So, I'll kick off with perl6-internals because, well, it's on the summary checklist (which goes something like: 1. Wibble about the weather or something before; 2. Start with perl6-internals; 3. Continue with perl6-language if it saw any traffic; 4. Make announcements, suggest people give money to the Perl Foundation; 5. Make sure Leon Brocard gets a mention; 6. Aspell; 7. Mail PODs to and a text version to perl6-announce; 8. Profit!)

NULL Px Proposal

Right at the end of the previous week, Melvin Smith suggested having the initial 'empty' PMC registers all point at a global PMCNull which would throw an exception if you tried to invoke any of its methods. Which sounds weird, but it does mean that you get a real exception instead of a segfault, and exceptions are so much more trappable. Dan liked the idea.

Melvin later posted a patch implementing the idea, which Leo Tötsch fixed up slightly an applied.

Parrot Calling Convention Confusion

Steve Fink is having problems using an unprototyped call to a prototyped function, which he thinks is a reasonable thing to do (and I think I agree with him; I can imagine cases where you have a function pointer or something where you don't know its exact prototype, but you do want to make a call to it so you'd be forced to make an unprototyped call.). Melvin Smith disagrees with him. Steve then went on to point out that he's still getting failures when the function is both declared and called in an unprototyped fashion. According to Leo, this is because unprototyped returns are neither defined nor implemented. Which is odd really -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call.

A clash of symbols

Arthur Bergman, Ponie stablemaster, popped up to point out that definitions like

#define version obj.version

(found in include/parrot/pobj.h if you're interested) did some scary things to Perl_utilize in the Perl 5 core. Steve Fink stuck his hand up to being the person who added the version field (which is apparently rather handy if you're debugging the Garbage Collection (GC) system. Leo fixed things by applying a s/version/pobj_version/g patch.

Storing external data in PMCs

Arthur popped up again asking for help with implementing a Perl5LVALUE PMC. It turns out that the API doesn't quite support what he needs. After a certain amount of discussion of various options Arthur proposed a Parrot_PMC_attach_data(Parrot, PMC, *void) extension to the API. He didn't *quite* get what he wanted, but he got something very like it later in the week.

I did like Arthur's reasons for starting the serious Ponie effort by working on Perl5LVALUEs though: ``[because] it is so obscure that it's hardly used anywhere and is limited to a few small areas in the core''.

Screaming Pumpkins Ahoy!

On Monday, Leo declared that yes, Melvin Smith's proposed Halloween 'Screaming Pumpkin' Parrot release would be happening. Various people promised extra goodies, and a few problems were sorted out with some platforms.

Features were frozen on Wednesday and Parrot 0.0.13 ``Screaming Pumpkin'' was released upon a cowering world at 2003103114:11:46 precisely. For all the astonishing speed of the release cycle, there's a lot of good stuff to be had in the screaming pumpkin, check out Leo's announcement for details. -- Leo's announcement

Header Dependencies

Jürgen Bömmels wasn't entirely happy with the way Parrot's headers are set up. Apparently there are some nasty dependency (and crypto dependency) issues. He proposed fixing up the headers as much as possible to eliminate these issues. Dan and Leo thought it would be nice, but Dan thought there wouldn't be that much point in doing it as things would probably decay, and pretty much everything internal should just be using parrot.h, and everything external should be using extend.h or embed.h.


Jürgen Bömmels triggered a quick bout of tinderbox fixing, as various different hardware experts helped to figure out why several of the tinderboxes weren't building and testing successfully. Jonathan Worthington submitted a few patches to clean up the various Win32 warnings. David Robins submitted similar patches to clean up some Solaris warnings.

Wrapping C/C++ libraries

Anuradha Ratnaweera asked a bunch of questions about how Parrot and Perl 6 would interface to external C and C++ libraries. The Leo and Dan provided the answers.

Broken Windows

(Sorry about the heading, I couldn't resist). Jonathan Worthington reported some breakage of NCI on Win32. He and Leo worked through the issues in search of a fix.

Garbage-collecting classes

Luke Palmer responded to the comment in last week's summary about the way to instantiate an object in class Foo being:

new P5, .Foo

He worried that, because classes are now simply integers, there was no way to garbage collect class objects if anonymous classes were used heavily. Jeff Clites, Leo and Dan all rushed to reassure him.

Parrot IO Fun

On Thursday, Melvin Smith announced that Parrot had fetched its first web page. Your parrot can fetch webpages too, just update to the latest, check out examples/io/http.imc and the world is yours. Everyone made impressed noises.

Melvin Smith, tease of the week

Melvin announced that, in his personal copy of Parrot he has most of the Class metadata declaration support working, but that he wouldn't release it 'til after the Screaming Pumpkin release. If it's as good as he promised, I guess we can wait.

Character classification functions

Noting the presence of the is_digit function, Peter Gibbs wondered if it would be useful to have a set of is_foo functions, or better to have a single is_ctype function with an enum parameter. He preferred the is_ctype option, and set about implementing it. Ever the speed demon, Dan thought it best to have a reasonable set of is_foo functions for 'common' chartypes and a fallback is_ctype function for the rest. Once they were all wrapped up in sensible macros that would mean that you didn't have the possibility of a very small speed hit getting multiplied up in the middle of a tight loop, but the programmer wouldn't have to worry about which types were checked in which fashion.

Moving to a new PMC compiler

Leo Tötsch posted a patch to switch Parrot over to using pmc2c2, the new version of the PMC compiler, but didn't commit it because his Makefile was playing up. He asked for some help to fix that before the patch could be committed.

Summary suggestion

Ron Grunwald suggested that it might be a good idea to include a glossary with each summary explaining what IMCC, PMC and PIR stand for (um... Incredibly Magnificent Compiler Compiler(?), Parrot Magic Cookie and Parrot Intermediate Representation(?) respectively) and maybe giving some explanation of other bits of Parrot jargon. Which is a jolly good idea. But laziness dictates that, instead I point you all at docs/glossary.pod which, following a gentle nudge on the mailing list, covers the above acronyms and more (but sadly some of 'em are missing from the Screaming Pumpkin release).

Meanwhile, in perl6-language

There was some real traffic. With questions. And Answers! What is the world coming to? Admittedly, there were only 10 posts in the week, but it's the quality that counts.

Alternately named arguments

Remember last week, when Luke ``Edgecase finder general'' Palmer asked about named return values and made David Storrs boggle? This week he was answered. By Damian. And Larry. Any question that elicits a ``Please, no!'' from Damian has got to be a good question methinks.

The question revolves around the statement in Apocalypse 6 that a list on the left hand side of a binding operator (:=) is interpreted in the same way as a function signature. Which means that you can use 'named' binding:

(who => $name, why => $reason) := (why => $because, who => "me");
   # ($name == "me") && ($reason = $because)

What elicited the ``Please, no!'' was Luke's logical conclusion that this could also mean that you could do:

(+$name, +$id) := getinfo();

and the unary + would be treated as a 'named only' marker in the same way it would be in a function signature.

Interestingly, Larry was less convinced that this was inherently a bad thing, though he did propose that, under most forms of stricture that it should only work in the case of:

my(+$name, +$id) := getinfo();

because the my helps the reader to realise that + may not be in Kansas any more without having to reach the := and then reinterpret everything that went before. (If you've heard Damian, Allison or possibly even Larry talking about Perl 6, you've almost certainly come up against the concept of ``end weight''; this is an example).

State of the Conway

It's been a while since Damian said anything in perl6-language, so David Wheeler welcomed both him and Larry back. Damian thanked him, and posted a short status report. While he's not been in quite the same state as Larry, ``mild influenza and a little light pneumonia'' don't sound like a barrel of laughs either. Anyway, he's back on the case when he can spare the time from putting food on the table.

Questions about currying

Joe Gottman had some questions about currying. Luke Palmer and Jonathan Scott Duff answered 'em. I'm getting quite good at this summarizing malarkey aren't I?

Acknowledgements, Announcements, Apologies

Whee! Monday is this week's Monday! What's the betting I can keep it up?

Those of you who've been reading this summary since almost the beginning will remember that I copped the basic 'chunks of text followed by a link or two' format/structure(hah!) of these summaries from NTK. Well, this Friday's NTK had some coverage of the state of Larry and Damian's health in their HARD NEWS section (

If you found this summary valuable, please consider one or more of:

  • Join in! The project needs people. http://dev/ and are good starting points for information.
  • Chip in! Money helps keep the wheels turning, programmers like Larry, Dan and Damian have families to feed and medical bills to pay, finding that money takes time away from getting Perl 6 out of the door. By donating money to The Perl Foundation you can help.
  • Chime in! It's always good to get direct feedback from readers. Drop me a line to let me know what you think at, I promise I'll reply (assuming it's not spam, in which case I shall simply wish recurrent hemorrhoids on you).
Visit the home of the Perl programming language:

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en