When Interpreters Collide

Note: this post is about implementing an M0 interpreter in Perl and is more a lightly edited braindump than a polished presentation of a concept.

Recently some test failures in M0's test suite revealed that the prototype Perl interpreter had been sneaking some of its perl-nature into the implementation.  The M0 assembler had been storing all values as strings and the interpreter had been secretly using its perlishness to convert the number-like values into ints at runtime.  This doesn't work well for an M0 implementation because M0 needs to be very specific about the low-level behavior of an implementation and the way it treats registers.

Perl is not C, and the basic problem I'm running into is that Perl is not designed to operate at the low level that M0 (as it currently stands) requires.  M0 is all about bytes and assigning meaning to the value in a register by using a certain classes of ops on it.  Perl is much higher-level and doesn't even have a particularly strong distinction between strings and integer values.  If I want Perl to have string byte-oriented C-like semantics, it means that I'll be widely (ab)using the bytes pragma and pack/unpack.  This is doable, but it's also torturing Perl into implementing something even further from its intended use case than the current (and subtly-incorrect) M0 implementation already is.  sorear rightly freaked out when he looked at the M0 interp code, because it's doing something that Perl wasn't intended to do and something that Perl isn't particularly well-suited to.

Still, javascript has been used to emulate at least x86, 6502, Z80 and 5A22 and  with surprisingly reasonable performance.  Arguably that's also pretty far from javascript's intended use case, and still it works.  This many just be an issue of finding the least hacky way to do something inherently very hacky.

The alternative is to specify M0 to have flexible underlying semantics, but I don't know that it'd be either practical or advisable to go too far down this road.  It's worth giving some thought to making the M0 spec be minimally unnatural to implement in a high-level language, but M0 is by its nature a low-level beast.  Implementations are bound to reflect that to some
degree.

In the end, the best way forward will probably be to plow through the craziness of implementing a simplified CPU in Perl and look forward to building on chromatic's C implementation, where the intent of the implementation language is much closer to the aim of the project.

Parrot has a new architect. What now?

Close followers of Parrot have probably noticed that Allison Randal, our esteemed architect, hasn't been very active over the last few months.  After her recent announcement that she'd been hired as Technical Architect for an obscure Linux distribution called "Ubuntu", folks might be wondering what Parrot's future looks like.  This is doubly true because the architect position has had a bus number of one.  If Allison were hit by bus or otherwise incapacitated, there was no structure in place to ensure that someone could step up and keep Parrot moving in a consistent direction.

Burnout has also been a problem for Parrot's past architects, partly because the architect ended up being responsible for managing most of Parrot.  We've done a great job of making Release Manager a straightforward process that can be performed by any Parrot developer with a commit bit.  The Release Manager position, however, has been the exception.  Most of the interesting roles, e.g. managing Parrot as a product or working with the wider OSS community, haven't been formalized and have fallen to the architect in the absence of someone willing to take the lead.  Allison is a capable leader and an A-list hacker, but Parrot has passed the point where it can be formally managed by a single volunteer, even one of her caliber.

It was in this environment that Jim Keenan put together a meeting of Parrot developers in Portland, Oregon.  Many topics were discussed, among which was a restructuring of Parrot to split responsibilities into separate roles.  Andrew Whitworth has already covered the idea in its current state, which will undoubtedly change as we progress.  The end result is that we'll be splitting responsibilities into 5 teams, only one of which will cover architecture.  We'll be solidifying the structure and formally voting on leads in the coming weeks, but interim leads have already volunteered for most available positions to get the process bootstrapped.  Andrew is provisionally in charge of the Product Management and in addition to posting some thoughts on the team structure, has already started fleshing out his vision for the Product Management team.

Then at last Tuesday's #parrotsketch meeting, Allison announced that she would be stepping down immediately, and that she had chosen me to succeed her as head of the architecture team.

What this means for Parrot's immediate future is that while I'll be the closest analog to Allison, Parrot won't rest primarily on my shoulders in the same way that it did on previous architects'.  It will be the architecture team's job to look to the future and determine where Parrot needs to go, but other jobs will be delegated to different teams, allowing all of us to specialize without letting anything important falling by the wayside.

Allison mentioned that after the meeting, she felt like a huge weight had been lifted from her shoulders.  She plans on staying with Parrot as a developer, but will be focusing most of her energy on Pynie.  For those of us wondering what Parrot's future looks like, we now have part of the answer and a reason for optimism.  It will take some time until we figure out just how the different teams will interact and what it means to be on a team, but the new team structure promises to help us become a more focused community and to produce a high-quality production-ready platform for interoperable dynamic language implementations.