Parrot of the future

#parrotsketch (the weekly design meeting for Parrot) was quite a productive meeting today. Parrot 1.1 is probably going to be released any minute now, if it hasn't been released yet.

I suggested the idea that we rip out the current JIT system, an idea that I had discussed on this blog and elsewhere previously. Though there was some support, it was generally decided that we shouldn't rip JIT out entirely just yet. I'm not going to argue the point, there are plenty of good reasons why not to (at least, not yet).

We also discussed an idea that chromatic had a while back, and that i've been growing increasingly fond of: rewriting PMCs and OPS files in a small special-purpose language, instead of writing them directly in C. The Parrot build process would convert these files into the various forms they need to be in for compilation: C code for the various "regular" runcores, and JIT code generating thunks for any future JIT cores. One of the biggest problems with our current system in my mind is that currently all ops need to be defined twice: once in ordinary C, and once for the JIT variant (actually, it's more then twice because we need to define a JIT variant for each platform). If we change one and not the other, we have breakage. Such breakage is particularly annoying because the JIT system is so murky and hard to navigate that fixes are slow in developing.

There are a lot of cool things that people would like to do in Parrot over the long term. Obviously there are some things that need to be tackled more immediately: the calling conventions reworks (on which Allison is currently doing a wonderful job), improved encapsulation of various subsystems (including GC ad JIT), replacing IMCC with PIRC, etc. There are also a number of features that need to be implemented from the ground up such as asynchronous IO and the whole security infrastructure. A self-hosting small language for Ops and PMCs is another cool little wishlist item that I hope we as a community decide to pursue.