This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit

The Perl 6 Summary for the week ending 2005-10-30

Hmm... Thursday afternoon and I've only just started writing the summary... What happened to professionalism? What happened to rigid, albeit self-imposed deadlines?

Um... I've had a cold. The cats ate my homework.

This week in perl6-compiler

It's weird isn't it? Activity on Pugs and the other Perl 6 compiler tools shows no signs of slowing (especially now conference season is over), but the volume of mail on the list continues to be tiny. Autrijus seems to be Erd\xF6sing round Europe and writing everything up on use.perl. I could give you a bunch of links to various other blogs and journals where various Perl 6 developers are writing up their work, but it's probably easiest just to point at the Planet Perl Six aggregator. It's good to see so much of this stuff becoming a little more visible.

Meanwhile, in perl6-internals

Discussion of the Parrot JSON serialization code span off into a discussion of generalized serialization for Parrot data structures.

Determining the number of return values expected

Leo and Jonathan Worthington discussed how to find out about the number and types of return values the caller expects. Jonathan ended up implementing an experimental op to kick around.

Rules for changing APIs

Leo talked about the Parrot policy for changing APIs. In general, it's a good idea not to have to change a public API, but in practice, it happens. As Leo said, the general rule is "You break it, you fix it", so the policy is that if any API changes break anything in the Parrot subversion tree, it's up to whoever changed the API either to fix it or to work with the the sub project's 'owner' to get it fixed. Projects that aren't in the tree will need to keep themselves up to date, but if you didn't document your changes well enough, expect to be fielding questions for a while after your changes.

check_progs is not portable

Fran\xE7ois Perrad pointed out that the check_progs subroutine used by Parrot's config system doesn't work on windows. He suggested using the CPAN module File::Which instead. This turned into a discussion about whether it would be good to have a Bundle::Parrot set up on CPAN with all the CPAN modules needed for Parrot to build, or if we should continue to bring those modules that Parrot needs into the Parrot distribution so that, once you've downloaded the Parrot tar file you won't need to scurry off to CPAN for various supporting bits and pieces.

The Configure System

Understating the case somewhat, chromatic pointed out that the plugin system for configuration is grotty. Everyone agreed pretty much, but the question is whether to do anything about it since the current configuration is supposed to be a stopgap solution until we get the proposed miniparrot scheme up and running. Pretty big gap eh?

Hopefully this means we're going to get work started on the miniparrot approach. Or maybe someone will clean up the stopgap. Neither would be bad.

Yet another C compiler

Leo pointed everyone at the Amsterdam Compiler Kit, which is the default compiler for Minix and wondered if anyone wanted to experiment with it to see if it could compile parrot.

Deprecation warning

Leo announced that the newsub operator is about to be removed. Check docs/compiler_faq.pod for details of the Right Way of making subs. Patrick had a few questions so he could track the changes in PGE. Leo answered them.

Compiling parrot with c++

Nick Glencross wondered if it would be a good idea to make it so that Parrot couple be compiled by a compiler in C++ mode. The answer appeared to be 'yes'.

Documenting new_pad

Jerry Gay asked about the use of the new_pad op, which appears to be both undocumented and untested. Not good. He posted some apparently reasonable code that fails. Matt Diephouse reduced it to a simpler failing case and Leo tracked down the bug. None of which addresses the lack of documentation of course, but it's a start.

"All tests successful" considered harmful

Jerry Gay pointed out that "All tests successful" is only a useful message when you're confident that your test suite has good enough coverage. Jerry thinks parrot has too few tests. So he's started writing more and sending in patches. He noted that trying to write tests was a very good way of discovering areas of Parrot that aren't sufficiently (at all) specced. He called for others to join him in writing tests and picking off parrot's low hanging fruit. Go Jerry!

One of Jerry's issues was that you can't easily write tests in PIR. So chromatic pointed him at his Test::Builder ported to PIR and committed to getting Parrot::Test (or some useful subset of it) ported to make use of it. Go chromatic!

Rejigging NCI to use the ffcall library

Nick Glencross wondered about rejigging NCI, the parrot Native Call Interface to use the ffcall library. In fact he went so far as to offer up a proof of concept implementation. Apparently the ffcall approach makes it much easier to write callbacks in PIR/PASM. Leo thought it sounded like a useful thing to do, but licensing issues (ffcall is under the GPL) meant that Parrot might have to stick with the current NCI interface.

Meanwhile, in perl6-language

That darned class sigil

I just can't keep track... When Larry originally introduced a class sigil, it was \xA2. The discussion went off in several directions and, as I write this and the next summary will probably say that the sigil is now longer \xA2 because of difficulties typing the character on Asian keyboards. The discussion was generally in favour of some kind of new sigil though.

Perl 6 Fears

Juerd announced that he's added a list of Perl 6 fears to the pugs distribution. The idea is to gather all the things that worry people about Perl 6 into one place and see what, if anything can be done to address them. People don't seem to like Unicode operators...

Slightly tangentially to this, Dan Sugalski blogged a couple of weeks ago about his successes and failures with Parrot. The comments are worth reading -- there's a fair few more or less well founded complaints about the way the Perl 6 project has been managed, many of which seem already to have been addressed. Certainly the design process is rather more visible now.

Ways to add behaviour

Ashley Winters has been thinking about all the different ways to add behaviour to classes in Perl 6. He came up with 7 and I think he missed a few...

A discussion between span off with Larry and Stevan talking about the hows of whys of adding behaviour via .meta, which in turn morphed into a wider discussion of how the Perl 6 metamodel's going to work. I find myself wondering what we're going to run out of first, Unicode characters for new operators, or terms for MetaModel concepts.

$_ defaulting for mutating ops

Quickly, what does a line of code like:

  given $subject { ++ }

do? Juerd thinks it should increment $_/$subject. The idea being that all mutating operators should default to operating on $_ in the absence of any other operand. Larry pointed out that, as you can already use . on any postfix operator, it's already possible to write

  given $subject { .++ }

He reckoned that changing the other operators in the way Juerd proposed would probably be a losing proposition. I'm not sure Juerd was convinced.

txt vs OO

Michele Dondi replied to Stevan's assertion of a few weeks ago that "Perl 6's OO system has the potential to be to OO programming what Perl 5 etc, was to text processing". Michele thought that being known for OO might well be as much of a trap as being known for text processing was for Perl 5 (at least to the wider community of programmers who didn't look further than the headlines). In the ensuing discussion, Larry came up with the idea that the design of Perl 6 is aimed at making it possible to 'usefully cargo cult aspects of interest' without having to learn the whole damned language. When the OED adds the verb form of 'cargo cult' to its corpus, remember where you read that first. Even if you're not that interested in the rest of the thread, it's worth reading what Larry has to say on this. -- Larry on cargo culting

+$arg changed to :$arg

Larry announced that one of the major changes in the latest version of Synopsis 6 was that named arguments are now marked with : and not +. The aspect of this that had me punching the air and shouting "Yes!" was that it's now possible to declare a parameter with both an external name and an internal variable name (which is one of the aspects of Smalltalk style method selectors that I really like). After a long post of thinking aloud, he went off to revise the synopsis again. Discussion of the implications of using : ensued.

Roles vs. Classes

Rob Kinyon wondered if the only difference between a Role and a Class was that the Role was immutable. He reckoned that, if that was the case he'd rather use Roles all the time. Luke, chromatic and Larry thought he was wrong about this, pointing out that open/closed optimizations should be left to the class's clients not to the class itself. Essentially, if everything declares that it's not going to monkey with everything else after the compile phase is over, then perl can get on and optimize like an optimizing monkey based on the (good) assumption that all classes are closed for the duration of the program's execution.

Is there a way to generate an object without a new?

Yiyi Hu doesn't want to have to type 'new', preferring instead to do Class( b => 5). Luke liked the idea. Juerd didn't. Larry pointed that making it work would have unpleasant syntactic ramifications.

Role Method Conflicts and Disambiguation

Stevan had some questions about how method conflict resolution works with roles. He had a few simple, if pathological cases to demonstrate the issues. Various solutions were proposed, but I did find myself thinking of the old joke: "Doctor, it hurts when I do this."

"Well, don't do that then."

Ahem. The old ones are still the old ones. And the Old Ones are still the Old Ones, but I don't think we've yet added "Perl Six will awaken great Cthulhu from his long sleep beneath the island of R'Lyeh" to the Perl Six fears list.

Crossing lists

Darren Duncan wants a 'simple way to combine 2 arrays where every element of each array is combined with every element of the other arrays', he calls this the cross operator. Luke pointed to several places where it, or something like it had already been discussed, but I don't think it's something that's made it in to the language.[]

Acknowledgements, apologies and everything else

Sorry it's late. I'll do better next time.

I'm still looking for work; perl or ruby programmer, photographer, tech writer, folk singer -- I'm multi talented. Let me know if you need any of 'em. Also, if anyone is interested in taking up sponsorship of the Summaries, please drop me a line, I'd be delighted to hear from you.

Help Chip -- Chip still needs help.

The usual coda

If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. -- The Perl Foundation -- Perl 6 Development site

Check out my website, it's lovely.

Vaguely pretty photos by me can be found at: