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 20021027

You may have noticed that this summary is late. Um... [looks sheepish, shuffles feet], the dog ate my homework. I did a tiny bit of procrastination at the beginning of the week and then got totally overtaken by events involving failed AC adaptors and general confusion. Sorry folks, it will probably happen again, but hopefully not in the near future.

So, kicking off, as is customary, with perl6-internals before getting down to attempting to summarize the monster that was perl6-language:

C# and Parrot

The dialogue with Rhys Weatherley and Gopal V from the DotGNU project continues apace, mostly to do with clarifying what C# needs in the way of datatypes and the like. It appears that Leon Brocard is the go to guy if you need to know the exact details of almost anything in a language spec. Maybe he's just really good with Google.

Gopal V wondered if there was someone involved in p5i who would mind acting as a liaison with the DotGNU people, who could give them a heads up when, say, the packfile format changed. Leopold Toetsch wondered what sort of changes were potential C# breakers, as there were probably things that we thought of as `internal' that the C# team could be depending on. Leo also thought that the liaison person should probably be Dan.

Scratchpad confusion

At the end of last week, Allen Short pointed out some discrepancies between the implementation of scratchpads and the description of them in PDD6. John Sillito reckoned that PDD6 was waiting on a rewrite from Dan, especially where Scratchpad PMCs were concerned as there were a couple of different patches waiting on Dan's say so. Dan also offered some clarification, but hasn't ruled on the Scratchpad PMCs yet.

Help! Bugs! Crawling all over me! OR The road to 0.0.9

Steve Fink wants the GC bugs ironed out before he goes adding much in the way of new features, and he wants to start putting together a 0.0.9 with working GC too. To that end he deliberately broke all the tests by turning GC_DEBUG on for tests. There's a certain amount of cleverness involved in how he did this; read his post if you're interested. Peter Gibbs found what he thought was a fix for a couple of the failures and pointed to the possibility of a fundamental problem in MultiArray as the culprit for the remaining failure. Steve applied this patch with much rejoicing, and then came up with a trial patch that seemed to fix the multiarray triggered failure. This patch had not been finalized by the end of the week.

Steve also kicked off discussion of the forthcoming 0.0.9 release, when he posted his list of prerequisites and sparked off a decent amount of discussion of various points. Steve's overarching goal for this release appears to be 'bug reduction and general consolidation'.

Keyed ops, the return.

I think it's safe to say that some people aren't entirely happy with keyed ops as they stand now in Parrot. The week before, Leopold Toetsch had written a proposal for keyed ops. This week he supplied a proof of concept patch. Jürgen Bömmels liked it but Dan took a little more convincing. I'm not sure he is entirely convinced yet, but he's willing to live with it.

64-bit ints and non-capable hardware

Dan announced that he was about to bite the bullet and declare that INTVALS have to be 64 bit integers and wanted to know of any (plausible) platforms that have neither native nor emulated 64 bit integers. Martin D Kealey pointed at what sounds like a scary proposal from C99 involving declarations and clever compilers and wondered if it might be a way forward for parrot. Rhys wondered how well the idea would play with something as dynamic as Parrot and the languages expected to run on it, but Martin didn't seem to think it would be much of a problem.[]

Configuring and DOD

Erik Lechak couldn't get the latest parrot to build on WinXP. Josh Wilmes diagnosed a problem with the way the configuration tools probed for stack direction, and patched things so that stack direction detection was done at runtime once more. Jason Gloudon, who had moved the detection phase out into configuration time wasn't sure that this was a good idea 'cos it would lead to a performance hit in the stack walking code. Nicholas Clark, with his clever head on, came up with three different ways of doing things at runtime without a performance hit, and Dan blessed the third choice.

Execute in place?

Rhys Weatherley has been taking a look at our packfile format code, and thinks it could be improved by designing the format in such a way that it can be mmapped into a block of memory and executed immediately, as opposed to the way parrot currently does it, which involves moving stuff around in memory before starting execution. Dan said that that's how things were originally done, and if it wasn't still possible then that was a bug.

Copyright notices and license stuff

Towards the end of the week, Dan announced that he was about to straighten out the copyright and licensing situation. As a first step, would be marking everything in the core as Copyright YAS. It looks like Parrot itself will be moving to an MIT style license `Over no objections whatsoever from the FSF'.

If you've made any contributions to Parrot's code base then you've probably already been contacted, but if you haven't and have an objection, you should contact Dan.

Most of the discussion of this happened in the next week, and I'll return to it in my next summary, but response was generally favourable following some clarifications from Dan.[]

Allow a NULL interpreter in sprintf like functions

Jürgen Bömmels sent in a patch which allowed the use of a NULL interpreter in sprintf like functions. Leo Toetsch applied it, but wondered if it was actually the Right Thing. Dan seemed to think that, in the long run, it probably wasn't and that, if something went horribly wrong before an interpreter got properly set up then it was probably best to use the standard library functions.[]

Draft sketch of bytecode generation

Dan offered a `very sketchy' draft of his thoughts on what we need from our bytecode generation system. Initial reaction seemed positive.[]

Meanwhile, in perl6-language

Won't someone please think of the summarizer?

There were around 150 messages in perl6-language this week. The *vast* majority of them discussing the Perl 6 built in operator list. It all started weeks ago, when Damian wanted |, & and the_as_yet_unnamed_xor_operator as superposition generating operators. But that meant we'd need somewhere else to put the bitwise operators. And people like ^ as xor, but that's not very possible because of hyper ops. And nobody likes _ as a concatenation operator. It's all got very complicated.

However, in answer to a summarizer's prayer, Michael Lazzaro has taken to posting a scorecard of his understanding of what the current list of built in ops is. (A list of diffs between these would be interesting to see...). Things that appear to be set in stone:

  • ~ is the new _, which was the new . and which nobody liked.
  • ~~ is the new =~. (Otherwise =~ -> match, and ~= -> string append could get somewhat confused...) !~ stays the same.
  • | and & make any and all type superpositions, respectively. Damian has an article on why superpositions are such a good idea forthcoming for The phrase `in constant time' will probably not be used.
  • Nobody has any idea what xor will end up as.
  • Some people are worried that changing things too radically from old Perl/Algol type syntax will make for a harder learning curve. Other people tend to think that not many programmers use bitwise ops in Perl at the moment, so the change shouldn't matter too much.
  • It's a real shame that so many Unicode characters are so hard to type.

Here's a list of Michael's various opcode lists. They're usually good entry points to the discussion. (Which is kind of fascinating...)

Character properties

Luke Palmer wondered if we were planning on having properties on individual characters on a string; something he felt was an essential feature. There was a certain amount of debate about the use of the word `essential' in this context, leading Luke to give some more information about what he was driving at before he was eventually persuaded that what he wanted was an ideal candidate for a module.

Perl6 Built in types

Michael Lazzaro asked for a list of Perl6 built in types and offered his own first cut at such a list. Larry offered some corrections, but reckoned that the list Michael had just posted was the nearest thing we had to a definitive list.

Power of Lisp macros

Adriano Nagelschmidt has been reading Paul Graham's articles about Lisp and its advantages, especially the macro system and wanted to know if the macros were really as useful as Mr Graham claimed, and whether it was worth adding something like them to Perl. General consensus appears to be "Yes, they're really good, and yes, Perl 6 will probably have something similar". Larry had an interesting post on the subject (no surprise there then...)

In Brief

There was a minor kerfuffle early in the week when the Parrot CVS repository ended up with the wrong permissions. Oops.

Leopold Toetsch has implemented the splice vtable method based on the semantics in PDD2. This sparked a short discussion about copying vs. cloning.

It looks like native types are going to get type numbers just like PMCs, but native types will be negative.

Rhys Weatherley added a bunch of infix operators to IMCC's syntax.

Jürgen Bömmels added `fingerprinting' to .PBC files. The idea being that parrot can fail at load time if it tries to load a ..PBC file that was generated with a different version of core.ops. The previous behaviour involved weird, hard to track down, runtime errors.

Some spam got past the perl6-internals filters. We were shocked.

Michael Lazzaro announced an updated Perl6 OO Cookbook at

Who's who in Perl 6?

Apparently nobody is this week. I appear to have run out of answer sets for the questionnaire. If you've been mentioned in this, or any previous summary and you've not already answered, please drop me a line and I'll send you the questions.

Acknowledgement, Apologies and all that Good Stuff

This summary was once again brought to you from my office on board the 0625 from Newark to London and from my comfy chair at home. Distractions were provided by Xmame, Perls of the North, broken AC Adaptors and my own natural `Procrastinate now!' instincts.

Proofreading services were provided by me. Having left it as late as I did, I just want to get this summary out of the door before next week's is due. So any speeling mistooks are orl myne.

And, the old refrain: If you enjoyed this summary, please consider one or both of the following options:

Any fee paid for publication of these summaries on is paid directly to the Perl Foundation.