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 20021208

Another Monday evening. Another summary to write.

Starting, as is becoming tediously predictable, with perl6-internals.

Another JIT discussion

Toward the end of the previous week, Leopold Tötsch posted something about the latest round of changes to the JIT core. Daniel Grunblatt was concerned that the current JIT wasn't doing the right thing when it came hardware register allocation and wanted to remove a some conditional logic. Leo didn't agree at first, but became convinced and Daniel's requested change was applied.

Fun with IMCC

Lots of things happened with IMCC this week:

  • David Robins posted a list of minor niggles (For instance, it turns out you can't ret early from a .sub) and suggested some remedies. Leo Tötsch mentioned that the IMCC Cabal (which would consist of Melvin Smith, Sean O'Rourke, Angel Faus and Leo if there were a Cabal. But, as everyone knows, There Is No Cabal) have been discussing several of these issues.

  • Art Haas had problems building IMCC, apparently bison didn't like the imcc.y file. Leo tracked down the problem (at the second time of asking, I think he might be slipping) and checked in a working fix.
  • Leo Tötsch made a pile of changes to IMCC to eliminate clashes between Parrot's PASM language and IMCC's PIR syntax, which had made it hard to mix the two. Full details of the changes are in his post.
  • Gopal V wondered if there was any way of feeding code to IMCC beyond simply writing to a file and running IMCC. He'd had to make a bunch of changes to the IMCC files that he used, and wondered if there was a Better Way. Actually he didn't so much wonder as propose the aforementioned Better Way, lifting ideas from DotGNU's treecc. He and Leo discussed things, worked out an interface and Gopal went off to implement something (Yay Gopal!)

  • Steve Fink posted a patch implementing a first cut at namespace support in IMCC. He wasn't at all sure that what he'd implemented was the Right Thing, but it supplied what he needed for the time being (if that makes sense) in the regex engine. Leo reckoned that it looked okay, and promised to apply it if nobody hollered. He also pointed out some problems with the current regex implementation to do with reentrancy and memory leakage. It turns out that Steve was working on languages/regex rather than the rx_* ops, which are the ones that have the problems.

  • Gregor N. Purdy had some problems with IMCC's syntax, a fragment of code that he thought should work fell over in a heap. Both Mr. Nobody and Leo pointed out that IMCC expects subroutines, and you should wrap your code in a .sub/.end pair.
  • Once Gregor had that straight he posted a Jako program and the IMCC code he thought the Jako compiler should generate from it and asked for any feedback before he went to change the compiler. Leo Tötsch provided some (I assume) useful feedback.

    A little later Gregor posted again, he was still having problems with IMCC not quite behaving as he wanted for the Jako compiler. He and Leo thrashed it out over a few messages and, to cut a long story short, IMCC looks like it won't be changing. I'm not sure whether Gregor is happy about this...

  • Mr Nobody posted a patch to get IMCC to compile under windows. Apparently the OUT label clashes with something in the windows header files. The patch got applied.
  • Gregor N. Purdy got a little confused by how IMCC generates PASM code, and posted some sample code, interspersed with questions. Which Leo answered. It's worth looking at this; it shows off the kind of optimization that IMCC gets up to.

PMCs are the thing

Dan announced that he's finally stopped waffling and frozen the PMC structures `modulo the odd twiddling to it.' He's added a pmc.ops file, and has started adding in ops to manipulate PMC internals. Leo asked for some clarifications, got some, and then wondered what the final 'Parrot Object' will look like.[]

logical_not issue

David Robins is having fun with logical_not and Ruby. The issue is that all integers in Ruby are true, whether or not they are zero but that with some of the assumptions in other PMCs. Robin offered 3 suggestions for how to fix it. Dan noted that it's an issue for Perl 6 too, since the truth or otherwise of a value can be modified by a property of that value, coming up with a fix is on his todo list. David wondered if this had been discussed before and offered another possible way forward. Dan half liked the idea but noted that the approach didn't work for and, or and xor, at least where Perl is concerned.

The language that dare not speak its name.

After a fortnight during which nobody made any comment on Leon Brocard's patch adding a brainfuck subdirectory to the languages directory, Nicholas Clark committed it in CVS.

At which point Andy Dougherty spoke up to say he wasn't happy about it, saying that he didn't wish to be associated with needlessly crude and offensive language. After some further debate the subdirectory was renamed to bf in such a way that, if you ask CVS it will tell you that the brainfuck subdirectory does not exist now and never has existed. Which seems strangely appropriate somehow. Fnord.[][]

Parrot Organization

Michael Collins asked about the structure of the Parrot development organization, and Dan provided some answers. My favourite Q&A:

Q. Is there any formal structure to this organization.

A. I [Dan] delude myself into thinking I'm more or less in charge....[][]

Just when you thought it was safe

to start using long file names with impunity, Mr Nobody pointed out that a bunch of the files in the parrot repository didn't play well with the MS-DOS 'filesystem's 8.3 naming rules. "So what?" asked Aldo Calpini. Mr Nobody asked if DOS was an intended compilation target. Answer: "No". The consensus appears to be "Ha! We laugh at your crappy filename restrictions and will not be jumping through any hoops to deal with a faintly silly hypothetical target." Or maybe that's just my opinion dressed up as consensus. Ah well, if I'm wrong I'm sure someone will tell me.

Meanwhile, over in perl6-language

The perl6-documentation team have been discussing String literals and their discussion spilled over into perl6-language as there are several things about them that are undefined and needed discussing by the language crowd. It's all to do with how octal numbers and octal string escapes are specified. Essentially, people don't like the current Perl5/C style 0101 (octal number) and \101 (octal string escape), so James supplied a list of the other possibilities. (The current Numeric literals doc say that 0c101 designates an octal numeric literal, but then the consistent extension to string literals (\c101 clashes with the current method of specifying a control-char). After a certain amount of debate Larry pulled one of his gloriously clear posts out of the bag, sketching the issues and coming up with a straightforward and obvious (but only with hindsight) way forward. It's good to be reminded why we trust Larry. Anyway, it turns out that an octal number will be specified using 0o101 and an octal character escape will probably be one of \0o[101] or \c[0o101] (I like the second better...)

Thinking about \c[...]

Once Larry had pulled \c[0o101] out of the bag, it fell to David Whipp to wonder what you could get up to with it. For instance, could you do: print "\c[71, 101, 108, 108, 111]" and have that print "Hello"? Damian pointed out that Larry had already discussed some of this in Apocalypse 5, but that the separator character would probably be the semicolon. Then Nicholas Clark got evil, and wondered about "\c[$(call_a_func())]", but Damian seemed to think that wouldn't be such a good idea.

Purge: opposite of grep

Miko O'Sullivan suggested a purge command which would be to grep as unless is to if. Nobody seemed to like the name that much, though most seemed to think the idea was sound. Michael Lazzaro suggested divvy which would be used to break a list into multiple lists (he initially proposed just breaking the list into two lists, but others extended the idea to more). Damian didn't like the name, and initially proposed classify, which would return a list of array references. Discussion continued for a while until Ralph Mellor suggested part as the name for this putative function, which Damian leapt on with a glad cry.

This went on for a while, with extra features being proposed and other explorations of the possibilities including some rather nifty proposed shorthand/DWIMmery.

Meanwhile Ken Fox wondered why we couldn't just implement classify/part/divvy as a normal sub and wondered why everything had to be built into the first version of Perl 6. So Damian implemented it, but commented that "then the thousands of people who are apparently clamouring for this functionality and who would have no hope of getting the above correct, would have to pull in some module every time they wanted to partition an array." Ken was impressed, and asked for some commentary on how it all worked, which Damian provided. BTW, this code is really worth looking at for an example of the kind of power that Perl 6 will provide.

David Wheeler wasn't over keen on calling the function 'part' because part has so many different possible interpretations. It turns out that that's why Damian likes the name so much. -- classify -- Damian implements part -- Damian implements part with sane formatting -- Damian explains it all

In defence of zero-indexed arrays

Michael G Schwern asked people to `Explain how having indexes in Perl 6 start at zero will benefit most users. Do not invoke legacy.'. Answers ranged from the silly to the sincere. The best answer was "Because I [Larry] like it" which, I think, trumps everyone.

Stringification of references

Joseph F. Ryan kicked off a discussion of the stringification of objects and references and offered his suggestions. Joseph leans towards having the default stringifications of objects and references provide information useful to the programmer. I agree with him (so, if you spot any bias in the upcoming summary that'd be because I'm biased). Michael Lazzaro explicitly brought up the distinction between "stringification for output" and "stringification for debugging", and came down in favour of stringification for output (heck, he even wanted references to be invisible to stringification). Piers Cawley told him he was very wrong and appealed to the authority of Kent Beck (a Smalltalk and Java programmer, possibly not the best authority to choose). Michael then proposed a scheme involving subclasses of String, to provide cues for different stringifications, which John Siracusa thought was going rather a long way too far, coming down in favour of the "stringify for debugging" position. I'm not sure anything has actually been decided yet though. Tune in next week.

Outline of class definitions in Perl 6

Simon Cozens asked for a translation of some Perl 5 style OO code into Perl 6, and Luke Palmer had a go at the task, then Larry came through with something a little more definitive (but not actually definitive just yet, I get the feeling that a few things are still in flux...)

Perl 6 and Set Theory

Luke Palmer posted a fascinating document presenting a "new way of thinking about some constructs." and proposed some changes to help with consistency. The document covered junctions and classes, recasting them as representations of finite and infinite sets. Only Damian responded with a few corrections and clarifications noting that one of Luke's proposed changes was rather fundamental, and that he wasn't sure he wanted to make that change without some deep reflection (from someone) on how that would affect the junction types that Luke hadn't considered. Discussion continues.

In Brief

Steve Fink is toying with adding OpenGL ops to Parrot.

Leon Brocard has used the native call interface features to add curses support to Parrot and offered a version of life.pasm that makes use of it.

The perl6-language crowd are currently working on string literals and stringification.

Who's Who in Perl 6?

I'm bumping this one up the questionnaire queue slightly. I felt the need for some controversy.

  • Who are you?
  • Abigail

  • What do you do for/with Perl 6?
  • Nothing, except for disliking languages that are white space sensitive.

  • Where are you coming from?
  • I've been coding Perl since 1995. Joined p5p in 1996 or so.

  • When do you think Perl 6 will be released?
  • A usable release? Given the current rate in which apocalypses are produced, I'd say 2008. Give or take a few years.

  • Why are you doing this?
  • I adore Perl. Perl5 that is. Programming in Perl5 is like exploring a large medieval castle, surrounded by a dark, mysterious forest, with something new and unexpected around each corner. There are dragons to be conquered, maidens to be rescued, and holy grails to be quested for. Lots of fun. Perl6 looks like a Louis-XVI castle and garden to me. Straight, symmetric, and bright. There are wigs to be powdered, minuets to be danced, all quite boring. I haven't been impressed by new features yet, but I'm disappointed by what will be lost.

  • You have 5 words. Describe yourself.
  • My mind is twisted. Backwards.

  • Do you have anything to declare?
  • One of the great things about Perl5 is that I don't have to declare anything I don't want to.


Another week of writing on the train and, for a change of scenery, at my parents' house, fuelled, as usual by large amounts of tea.

Proofreading was once again down to Aspell and me. Any errors this week are probably my fault, it's about time I started accepting my responsibilities.

Thanks to everyone who has sent me questionnaire answers, I've got a queue of about four left so, if you work with Perl 6 (or, like Abigail, hate it) please answer the same set of questions Abigail just answered and send them to me at mailto:[email protected] Thanks.

I got some mail last week from someone praising me for the summaries (thanks), but wanting to know how he could contribute his time and energy, so this week the chorus has a few extra lines in it:

If you didn't like the summary, what are you doing still reading it? If you did like it, please consider one or more of the following options:

  • Send money to the Perl Foundation at donate and help support the ongoing development of Perl 6.
  • Get involved with the Perl 6 process. The mailing lists are open to everyone, and are good starting points with links to the appropriate mailing lists.
  • [email protected] (No, I'm not unemployed at the moment, I just want to work nearer to home...)'>Send feedback, flames, money and or lucrative employment in the Doncaster area to mailto:[email protected] (No, I'm not unemployed at the moment, I just want to work nearer to home...)

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