Perl 6, Parrot and Recent Developments

Hello all.
    There's been a load of discussion about the implementation of Perl 6 in 
various places recently: at TPC, on language-dev, on python-dev, and in
various emails shot back and forth between some of the participants.
Conspicuously missing in that list of places is perl6-internals, where
very little has been going on of late. Part of this is my fault, and I
apologise for not keeping people in the picture.
    Here's a summary of what's going on at the moment:

    There was an opcode BOF at TPC, attended by Dan, Uri, myself, Bryan
Warnock, Hugo and Sarathy. Bryan's weekly report covers this in as much
detail as I can remember. It's been a long month. :)

    If you're not on language-dev, get on language-dev! Lots of interesting
discussion goes on there that isn't necessarily Perl6-specific, (in fact, is
explicitly *not* Perl6-specific) but is still extremely useful to what we're
doing.

    Eric Raymond asked python-dev to think about the possibility of working
with us to make Parrot run Python bytecode. There was a long thread about
this, which you can find in the python-dev archives. Now, our take on this is
that running other languages' bytecode is definitely something that we would
like to do; that was an idea that we were trying to support long before
Eric independently came up with it, so Parrot's language-independence is
something to strive for. However, Parrot is primarily the Perl 6
interpreter, so we will *not* tolerate running other people's bytecode
at the expense of Perl 6 speed. Thankfully, Dan and I have worked out a
way to do achieve language independence without loss of speed, (or rather, Dan
worked it out, and then some weeks later, a light went on in my head and it
all made sense) which I'll write up when I get more time.

    So far the status with the Python people is that this is an experiment
that ought to be pursued, but there is no "official" backing for it from
Guido. This is fine - we need to prove ourselves. They are open to the idea,
but not committed to it until they see how it'll work or Guido hears Larry's
stance on the idea. As well as that, there are Python people happy to talk to
us about how to accomodate their needs without compromising our own. Again,
language-dev is one place where this is happening, because people over there
are pretty hyped about the idea of a shared bytecode interpreter as well.

    So we need to prove the idea, and that's what I'm working on at the
moment. I'm doing this on two fronts: I'm writing a little paper which just
sketches out what we want from the Parrot interpreter and some preliminary
technical details about how it'll work, and how it'll run Perl fast and other
languages as well. This is not a PR exercise as such, and it's not for
"public" consumption - it's just so that *we* know what we're doing, and so
that people from other languages (such as Guido) can pick up the gist of our
ideas. 

    The other front is, of course, code. I have started writing some code
which sets up vtables, marshals access to an object's method through its
vtable, and helps you write new object types. I'm also trying to develop an
integer object type. All it does at the moment is the infrastructure that
allows you to create a new integer PMC and get and set its value.

    To answer the obvious question, I don't want to make the code public at
the moment. This is not because I have anything to hide - this is because
the code is fundamentally unhelpful. First, Dan is having a look over it to
make sure it fits his idea of what PMCs and vtables should look like.
Preliminary mails from him sound like I've got a lot of work to do before it
conforms with his mental picture. As soon as Dan and I agree on how the code
should look, I'll fix it up, write some documentation and make a tarball
available. 

    Again, I hope you'll understand that I don't want to make this
available at the moment because it may not be anything like what it is
supposed to be. Not only that, but since the first code we put out to the
world is the example that you'll have to follow when writing methods and
things for Parrot, it has to be *right*. But at the moment, we *do* have 
some code that needs major fixes, which is better than having no code that 
needs completely writing. :) I'm going to put a lot of work into Parrot
over the next couple of weeks, so there will be code for you all to pore 
over soon, I promise.

    So there you are. That's where we're up to at the moment.

-- 
"The best index to a person's character is a) how he treats people who can't 
do him any good and b) how he treats people who can't fight back."
-- Abigail Van Buren

• Perl 6, Parrot and Recent Developments by Simon Cozens