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 20030209

Welcome to the latest Perl 6 summary, your handy cut out and keep guide to the goings on in the crazy world of Perl 6 design and development.

It's been a rather quiet week this week; only 75 messages in perl6-internals and a mere 57 in perl6-language. So, at least it's palindromic.

We start off, as is traditional, with perl6-internals

The 2004 Performance challenge

Dan announced that he'd made a bet with Guido van Rossum that Parrot would be faster at executing a pure python benchmark of some sort to be determined. The details of the challenge will be announced at OSCON 2003 and the results at OSCON 2004. Dan stands to lose $10 and a round of beer for the Zope/Pythonlabs folks. (Dunno how many of them there are though...). We don't know what he stands to win yet, but I'd hope 'beers from each of the Zope/Pythonlabs folks' are included.

For some reason nobody commented on this.[]

More Parrot Objects

Jerome Quelin wondered how Parrot objects would handle property inheritance. Dan pointed out that properties don't get inherited and Jerome realised he meant to ask about attribute inheritance. Attributes are inherited but are mostly invisible to any methods but the methods of the class that defines the attributes (though they will be accessible (presumably through reflection)).

In another subthread, we got confused by multimethods. -- Multimethods

Bytecode Metadata

James Michael DuPont wanted to know what had been decided about Bytecode metadata and outlined the things that he'd like to know about a given bytecode. Leo Tötsch reckoned that what James wanted was either in the bytecode right now, or was handleable by the framework that was in place. He pointed James to docs/parrotbyte.pod in the Parrot distribution.

Further discussions centred on the amount of metadata and whether this would affect loading speed and efficiency, or get in the way of the desired 'mmap and go' principle. Gregor N. Purdy pointed out that we also had to be capable of passing meta data from a compiler 'through' IMCC and on to the final bytecode. There was also a touching reunion between James Michael DuPont and Gopal V. Ah...

Multi programming language questions

Phil Hassey has been lurking, fascinated on the internals list for a couple of months. This week he broke the silence by asking a couple of questions about cross language function dispatch, string compatibility and global scopes. For instance, PHP, Common Lisp and others are case insensitive about functions. Which is okay when you're calling such a function from a case sensitive language, but can be tricky if you call out from a case insensitive to a case sensitive language. Dan thought that there wasn't going to be much that could be done about this problem (at least, not transparently) but seems to think that the other issues raised shouldn't be too problematic.

Random questions

David popped up and, after remarking on the amount of progress Parrot had made since he last looked at it, had a few questions about various bits and pieces. Leo and Dan provided a bunch of good answers.

A Scheme for extending core.ops

Leo Tötsch seems to have got bored of 'just' being the Patch Monster and has been producing some discussion documents proposing all sorts of useful tricks for improving the design/speed/extensibility of Parrot's internals. This week he turned his attention to core.ops. His plan involves a way of reducing the size of core_ops, improving cache locality and generally solving a raft of problems I didn't even know Parrot had. His new scheme allows for a small core.ops, easy extension and no execution speed penalty for non core ops. As is usual with Leo's stuff, the scheme came with code. Gregor had a bunch of observations and suggestions and he and Leo thrashed out a slightly modified scheme for going forward.

Week of the alternative runloops

Leo Tö offered a couple of different core runloops this week. First up was the Computed Goto Prederefed (CGP) runloop which, essentially combined a two runloop optimization techniques to provide what can only be described as massive speedups. The -O3 compiled version ran parrot_mops 6 times faster than the basic 'fast_core' and more than 3 times faster than the previous fastest core. People were impressed.

A few days later, Leo reached into his bag of tricks and pulled out the CSwitch runloop that did predereferenced dispatch via a big C switch statement. This loop is about 50% faster than the basic fast_core loop, but slower than all the computed goto dispatched loops. At this point Jason Gloudon pointed out that predereferencing can cause problems in a multi threaded environment.

Quote of the Parrot development process so far:

"I'm a really bad C programmer" -- Leo Tötsch

And that about wraps it up for perl6-internals this week. Dan's been busy in Sebastapol with the Perl 6 Cabal thrashing out the design of Perl 6 functions and other bits with Larry, Damian, Allison and chromatic, which probably explains why he's not been driving the mailing list for the week.

Meanwhile in perl6-language

It's been even quieter on the language list. Mostly interesting though.

Shortcut ?=

Miko O'Sullivan proposed a new assignment operator, $var ?= $x : $y, equivalent to $var = $var ? $x : $y. It was pointed out that, for correctness that should be ??=. Deborah Ariel Pickett wondered what was the need for such an operator and couldn't imagine ever needing such an operator.

Language Discussion Summaries

Miko O'Sullivan proposed that members of the language list provide summaries of the discussions in the group [What's this? Chopped liver? -- Ed]. The idea being that each summary would describe a proposed idea and then summarizes the list's feelings on the idea, and would be posted on a website. The idea was basically well received, then the list fell to quibbling about format, whether summaries should be posted to the list where they could be picked up by the list summarizer, and whether we were just reinventing RFCs all over again.

As of now, the only summary that actually exists is Miko's summary of the proposed ??= operator. Which I hadn't even bothered to read until I came to write the summary. -- Summaries website

Newline as a statement terminator

Stéphane Payrard confessed that he would like newline to be a statement terminator everywhere it can be. Everybody hated it. Deborah Ariel Pickett came up with a neat example of why it was a really bad idea with a simple ambiguous piece of code:

  sub foo 
  print "abcde"
  if $condition
  print "fghij"

which could mean either:

  sub foo {
    print "abcdef" if $condition;
    return sub {
      print "fghij";


  sub foo {
    print "abcde";
    if $condition {
      print "fghij";

And disambiguating with indentation is way too Pythonesque for many.

Arrays vs. Lists

In his quest to exhaustively document what is known about Perl so far, Michael Lazzaro asked for a definitive answer to the question "What's the difference between an array and a list in Perl 6"?

Various answers were given but I think Uri Guttman came up with the most succinct pair of definitions, which reduce to 'lists are read only, arrays are read/write'. (That's the data structure itself, not the data structure's contents, ($a, $b) = (1, 2) doesn't modify either list, but it does modify the lvalues in the left hand list). -- Uri's definitions

Announcements, Acknowledgements and Trip Planning

This week's summary was prepared in the comfy chair with distractions from cats, irc, former employers, bugs and poring over maps of the Eastern Seaboard.

We're coming to America. This year, making a virtue out of a necessity we're going to give ourselves a good long holiday in the States. We'll be flying out to Boca Raton for YAPC, then taking a road trip up through the Appalachians to New England, possibly swinging into Canada before coming down through Michigan to Chicago and taking a slow train to Portland, OR for The Perl Conference. If it looks like you might be on our route, drop me a line...

Proofreading services were provided by Aspell and me. (I could lie and say that they were provided by Leon Brocard, enabling me to work his name into the summary somehow, but I think I'll do it in a parenthetical comment instead.)

If you appreciated this summary, please consider one or more of the following options:

This week's summary was sponsored by Darren Duncan. Thanks Darren. If you'd like to become a summary sponsor, drop me a line at [email protected]'>p[email protected].