|There's more than one way to do things|
DISCLAIMER: This is a controverse opinion on several matters, and must be understood with a IMHO before every sentence. And all the critics made to other people are intended in the most positive way, and not to make them look bad.
The Perl 6 development have basically two different approaches in course, one focused in the Virtual Machine, which is the Parrot project, and other focused in the language itself, which is Pugs.
The Parrot project aims to build a state-of-the-art virtual machine, and is, in several aspects, a trully impressive vm. Parrot already have a lot of features and can already run an impressive set of languages.
The Pugs project (and here all its child-projects are counted), on the other hand, started as an effort to implement the semantics of the Perl 6 language in "whatever" runtime. The first exercise was Haskell, but some other started soon after, most notabily, the Perl 6 on Perl 5 efforts of v6-alpha, MiniPerl6 and at last, KindaPerl6.
Some marginal efforts come and go along the way, like the Lisp backend to KP6, and YAP6, which is what this post is about.
Why does it take so long?
Seriously, everybody wants Perl 6 out. So, what's the problem? Again, let's look at the two different focus in Perl 6 development.
On the Parrot side, the project took a very hard challenge, which was to create from scratch a software that, at its first version, should be better than perl 5.10. This is an important challenge, in a way that if that is not taken, the project itself may seem pointless. A good analogy I like to make on that is comparing Parrot to GNU Hurd. GNU Hurd isn't out yet because they just can't fix things with hacks in it, simply because if they do it, hurd would simply be yet another operating system.
Parrot is today very powerfull and even in the first versions, it can already be used to a lot of stuff. But it still have a long way for hosting a full Perl 6.
On the language side, the specs are anything but stable, and the lack of a runtime that is actually capable of performing all the semantics the language creates, the concepts can't be tested, and therefore, can't be made stable.
The KP6 project have tested several possible backends, being the P5 the most successfull today. The KP6 tests looks very promising, with features like gather/take. Lazy array and hash autovivification.
On the other hand, the performance is absolutely unpractical, this implementation can only be used as a proof-of-concept. And, in terms of concept, it's fair to say that the concept do work.
Maybe for the first time, a real convergence between the Parrot and Pugs (actually KP6) "communities". There's an effort of porting the features of KP6 to Perl-6-on-Parrot and stablish a cooperation in the two projects. I hope this leads us to a viable short term implementation, but unfortunally, I have to say that we still have a long way to go.
When I and fglock were in the plane to vienna for YAPC::EU::2007, we were discussing how could we make KP6 faster, and at some point we considered and started sketching some structures in C. And at that point I considered the option of creating a as-simple-as-possible runtime in C to run KP6, and that was called YAP6.
During YAPC::EU, I had the opportunity for a very intesting debate with the parrot team about one of the most dense concepts of Perl 6, which is the inter-language interoperability. We didn't came to an agreement on this matter, and I started to become more skeptical about this specific issue, because I realised that in one way or another a typemapping would be necessary. And that typemapping would not be that different from what XS is today. This put my eyes back on how p5 works, and that's when I started taking yap6 seriously.
YAP6 today already implements some types, as the tests show, and it's really near having a practical use as a KP6 backend.
The idea is simple: Let's get the simplest C runtime that can run Perl 6 contexts and requirements and build a interpreter just like perl 5, but with the data structures following the ideas that had grown in KP6.
The main difference between perl 5 and yap6 is the concept of "responder interface" (those who saw nothingmuch's talk in YAPC::EU are familiar with that concept). YAP6 uses DISPATCHERs (as yap6 calls responder interfaces) for absolutely every type. And, like perl 5, implements a set of binary-compatible C structures resambling object orientation to interact with the data. Instead of SV* you have YAP6__CORE__Value*, instead of AV* you have YAP6__CORE__List* and so on.
So, what now?
Well, this post is actually a call for help. If you can program C, if you have any knowledge on the perlguts you certainly can help delivering the version 0.0.2 of YAP6 which will implement the basic runtime on top of which the interpreter in itself will be implemented.
The project is hosted in the pugs svn http://svn.pugscode.org/pugs/v6/yap6/, the README and the ROADMAP documents are a good guide to understand the project. The test files (all the t_*.c files in src/) are a very good way to see the runtime library working. #perl6 at freenode is the place to discuss ideas and implementation. Anyone wanting to help just stop by and commit instructions will be handed.
As I said before, and as I say in the README file, this is not completely a competitor to Parrot as it have different goals, and I certainly think that both projects can happily coexist and share much of the experiences. And I do think that we can have a YAP6 1.0 version very soon.