One question we occasionally hear is: "Can't we just ditch this Parrot
thing and implement Perl 6 on
On the surface, the two are very similar. Both have the goal of acting as a host for multiple languages and allowing interoperability between those languages (that is, allowing libraries written in one language to be loaded and called from code written in another language). Both take the strategy of compiling source down to an intermediate form and then to bytecode (there's nothing original there).
Why is it important to develop Parrot?
Mozilla has a tagline that appears over and over again in their documentation and press releases: "promoting choice and innovation on the Internet". This is an important mission. In fact, I'd take it a step further: "promoting choice and innovation in technology". Parrot fills the same role in virtual machines and compiler tools that Firefox fills in browsers and Linux fills in operating systems.
I won't go into the potential legal issues of Mono/.NET here, except to note it as another reason for innovation. There are plenty of places you can read about the issues if you're interested.
What are some of the innovations of Parrot?
.NET's Common Language Infrastructure (CLI) addresses language interoperability by constraining the high-level semantics of the languages that run on it (defined in the Common Language Specification, or CLS). Individual compilers can choose to ignore the contstraints, but if they do they're marked as "non-compliant", and can give up hope of interoperability (as well as other privileges). These constraints hinder the natural evolutionary process of computer languages, thereby presenting an obstacle to innovation.
Parrot takes a very different approach to interoperability. Rather than constraining high-level semantics, Parrot's constraints are at the assembly language level. Basically, your high-level language can do anything you want, the compiler just breaks the steps down into a series of low-level operations. This isn't a terribly strenuous demand, as the semantics are constructed from low-level operations anyway (ultimately all languages compile down to machine code). The objects shared across languages have to be able to perform (or intelligently decide not to perform) a set of assembly language operations, but they don't have to guarantee any particular high-level semantics. As Larry put it when we were asked this question at Google recently, "We won't try to make every language into C#."
Parrot targets dynamic languages.
While most VMs are stack-based, Parrot is register-based. This means Parrot can take advantage of decades of research in optimizing register-based (hardware) machines. It allows greater encapsulation and control in the internals of Parrot. As far as we can tell so far, it's also a speed advantage, as it significantly reduces the number of operations spent moving data around. One of the complaints about register-based machines has been that while stacks are virtually unlimited, you always run out of registers. Parrot solves this by allowing variable-sized register frames (that is, a virtually unlimited number of registers, with the number of registers varying from one compilation unit to another).
Parrot uses a continuation passing style (CPS) of control. Rather than pushing a return address onto a control stack before a call and popping it back off when the routine is done, CPS captures a continuation (containing all the lexical variables, control context, and meta-information about the caller's environment), passes it into the called routine, and invokes that continuation when the routine is done. For a detailed explanation, you can't do better than read Dan's blogs on CPS and why Parrot went with it. CPS has advantages for optimization, security, and for ease of implementing modern language features like coroutines, generators, exceptions, and backtracking in regular expressions.
One of the core goals of Parrot is cross-platform support.
And those are just a few points.