I understand why you want to use Perl to write Perl. But that's not the only path to "Christmas", and frankly, perhaps not even the most promising one (initially). Also, a non-bootstrapped implementation could be useful in either case, so why is there no alternative project to write a straight-forward interpreter in plain ANSI C? That's what Lua did; making especially sure that compiling Lua is as simple as "gcc *.c". And look at how popular it is, despite being such a poor language.
— monomorph, [Perl 6] Thoughts
One of the goals of Perl 6 is to create a family of languages through lexical grammar modifications. That is, programmers should be able to create their own local (and encapsulated) Perl 6 dialects by modifying the Perl 6 grammar by writing Perl 6 code.
This implies that you either write a very clever parser in ANSI C that's modifiable lexically by a language hosted on the rest of the platform or you write a parser engine that runs a set of rules encoded in a data structure generated by a language hosted on the rest of the platform. In practice, both approaches are basically the same.
(An alternate approach is to implement the subset of Perl 6 that doesn't support lexically modifiable grammars, but then you can't call it Perl 6 because you can't pass the specification tests. Removing features is an easy way to reduce the amount of work required for a project. The tradeoff is that you can't use those features.)
monomorph asked another question, so here's a bonus answer for free.
Why does every single P6 project try to do "too much"? (I know this is entirely subjective.) Pugs is not only [Perl 6] interpreter, but also a compiler with multiple unmaintained back-ends. Parrot will be the ultimate runtime, and to that end has introduced (and deprecated) more intermediate compiler formats than it ever supported (non-toy) languages.
I won't speak for Pugs, and I don't know what it means that Parrot has deprecated an intermediate compiler format. (I also suspect that that statement is incorrect, if it means what I think it may mean.) I think a better question may be:
Isn't the goal of supporting languages other than Perl 6 on Parrot making Parrot take way too long to reach 1.0?
The snippy answer is that Parrot needs to support Perl 5 code in process to meet one of the goals of Perl 6. This is not a trivial task. I wrote some experimental code on a train in January 2007 that used Parrot to dispatch some of the Perl 5 opcodes. To make this work I had to wrap Perl 5 SVs and AVs in Parrot PMCs. Working around two different garbage collection systems (Perl 5's reference counting and Parrot's actual garbage collection) was non-trivial. Toy programs can safely leak memory and have occasional crashes when you forget to pin an object passed back into the reference counting system, but correctness is occasionally important in programs.
Running Perl 5 code on a Perl 6 VM means either reimplementing all of Perl 5, from the parser on up, or embedding Perl 5 and wrapping all of its data structures anyway, at least if you want Perl 5 code and Perl 6 code to interoperate.
This means that any Perl 6 virtual machine that meets the goals of Perl 6 has to be able to support two similar languages with different syntax and semantics at the same time in the same process with interoperability between them.
If you're a language junkie like me, you've probably noticed that Perl 6 supports just about every feature in just about every other dynamic language in widespread use, if you remove the surface syntax. Any Perl 6 virtual machine that passes the Perl 6 specification tests probably supports just about every operation necessary to pass the Python specification tests, the Lua specification tests, the Ruby specification tests, the PHP specification tests, the EcmaScript specification tests, the Tcl specification tests, and likely even the Smalltalk specification tests.
Even further, if the grammar system and compiler tools used to build Perl 6 (and host Perl 5, however that happens) are sufficient to build Perl 6 well, they should be sufficient to build all sorts of new languages, some written in Perl 6 and some not. They should also be sufficient to port existing languages to Parrot.
I realize this doesn't answer a potential objection, namely "But aren't you dividing the available volunteer effort by trying to make other language run on Parrot?" Of course, the answer to that is "That's not how volunteer development works. That's not even how experimentation works."
While I'm sure that it's possible to write a VM to host Perl 6 that initially starts off simpler than Parrot, I'm sure that it will end up looking a lot like Parrot by it gets to the point where it can pass most of the Perl 6 specification tests, especially if it wants to run on multiple platforms, support the Perl 6 concurrency model, expose continuations, present a usable FFI, allow object composition and introspection and metaprogramming, and interoperate with Perl 5 code, not to mention host lexically modified grammars.
That's the clearest exposition of the "why" of Parrot I've read, thanks.
Exciting, isn't it?
