Parrot FAQ - Frequently Asked Questions
Fixed up the licensing bits
Translated to POD and added "Why aren't we using external tool or library X?"
Added the "Parrot and Perl" section and "Why Re-implement Perl". Incorporated Dan's Q&A items.
Adopted from Simon Cozens's article, "Parrot: A Cross-Language Virtual Machine Architecture".
Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.
The name "Parrot" relates to Simon Cozens's April Fool's Joke where Larry Wall and Guido van Rossum announced the merger of the Perl and Python languages.
When not orchestrating elaborate pranks such as this, Simon spends a modicum of time as Parrot's lead developer.
No. Parrot is an implementation that is expected to be used to execute Perl6 programs. The Perl6 language definition is currently (December 2001) being crafted by Larry Wall. While the true nature of Perl6 is still unknown, it will be substantially similar to Perl as we know it today, and will need a runtime system. For more information on the nascent Perl6 language definition, check out Larry's apocolypses.
Well, almost. :^)
Parrot is in the early phases of its implementation. The primary way to use Parrot is to write Parrot assembly code, described in PDD6.
You can also create dynamic content within Apache using Ask Bjorn Hansen's mod_parrot module. You are strongly advised that mod_parrot is a toy, and should not be used with any production code.
Lots of reasons, actually. :^)
All the cool kids are doing it.
It's a neat hack.
You get all the pleasure of programming in assembly language without any of the requisite system crashes.
Seriously, though, programming in Parrot assembly language is an interesting challenge. It's also one of the best ways to write test cases for Parrot.
It depends on what you mean by real. :^)
Leon Brocard has released a proof-of-concept Java bytecode to Parrot bytecode compiler.
Gregor Purdy is working on a little language called Jako that targets Parrot bytecode directly. (Available with the Parrot distribution.)
Dan Sugalski and Jeff Goff have started work on compiling Scheme down to Parrot bytecode. (Available with the Parrot distribution.)
C.
Because it's the best we've got.
So true. Regardless, C's available pretty much everywhere. Perl 5's in C, so we can potentially build any place Perl 5 builds.
Because of one of:
Not available everywhere.
Limited talent pool for core programmers.
Not fast enough.
The most common issues are:
License compatibility. Parrot has an odd license -- it currently uses the same license as Perl 5, which is the disjunction of the GNU GPL and the Artistic License, which can be written (Artistic|GPL) for short. Thus, Parrot's license is compatible with the GNU GPL, which means you can combine Parrot with GPL'ed code.
Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this.
Platform compatibility.
Parrot has to work on most of Perl 5's platforms, as well as a few of its own. Perl 5 runs on eighty platforms; Parrot must run on Unix, Windows, Mac OS (X and Classic), VMS, Crays, Windows CE, and Palm OS, just to name a few. Among its processor architectures will be x86, SPARC, Alpha, IA-64, ARM, and 68x00 (Palms and old Macs). If something doesn't work on all of these, we can't use it in Parrot.
Speed, size, and flexibility.
Not only does Parrot have to run on all those platforms, but it must also run efficiently. Parrot's core size is currently between 250K and 700K, depending on compiler. That's pushing it on the handheld platforms. Any library used by Parrot must be fast enough to have a fairly small performance impact, small enough to have little impact on core size, and flexible enough to handle the varying demands of Perl, Python, Tcl, Ruby, Scheme, and whatever else some clever or twisted hacker throws at Parrot.
These tests are very hard to pass; currently we're expecting we'll probably have to write everything but the Unicode stuff.
Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that perl would run more slowly there than on an interpreter geared towards dynamic languages.
Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.
Good question.
At The Perl Conference 4.0, in the summer of 2000, Larry Wall announced that it was time to recreate Perl from the ground up. This included the Perl language, the implementation of that language, the community of open source developers who volunteer to implement and maintain the language, and the larger community of programmers who use Perl.
A variety of reasons were given for embarking on this project:
Perl5 is a stable, reliable, robust platform for developing software; it's not going away for a long time, even after Perl6 is released. (Proof: Perl4 is still out there, no matter how much we all want it to go away.)
We have the ability to translate Perl5 into Perl6 if necessary. This preserves backward compatibility with a large body of existing Perl code, which is very important.
The language can stand some revision: formats don't really belong in the core language, and typeglobs have outlived their usefulness. By revising the language now, we can make Perl better.
Some warts really should be removed: system should return true instead of false on success, and localtime should return the year, not the year - 1900.
system
localtime
It would be nice to write the Perl to Bytecode compiler in Perl, instead of C. That would make it much easier for Perl hackers to hack on Perl.
Sure. Why not? C, Java, Lisp, Scheme, and practically every other language is self-hoisting. Why not?
No, not really. Don't forget that we can use Perl 5 to run Perl 5 programs, such as a Perl 5 to Parrot compiler.
We don't know yet, since it depends on the Perl 6 language definition. But we could use the more appropriate of two Perl compilers, depending of whether we're compiling Perl 5 or Perl 6. Larry has mumbled something about a package statement declaring that the file is Perl 5, but we're still not quite sure on how that fits in.
package
Probably.
No, Parrot won't be twisted enough for Damian. Perhaps when Parrot is ported to a pair of supercool calcium ions, though...
You had to be there.
Not much, why do you ask?
No, in fact, I don't.
Like what? There's just the JVM.
What others? That's it, unless you count Perl, Python, or Ruby.
Yeah, right. You never thought of them as VMs, admit it. :^)
Seriously, we're already running with a faster opcode dispatch than any of them are, and having registers just decreases the amount of stack thrash we get.
The 68K emulator Apple ships with all its PPC-enabled versions of Mac OS.
Really.
April Fool's Joke: http://www.perl.com/pub/a/2001/04/01/parrot.htm
apocolypses: http://www.panix.com/~ziggy/
cool kids: http://use.perl.org/~acme/journal
Java bytecode to Parrot bytecode: http://archive.develooper.com/perl6-internals@perl.org/msg03864.html
http://www.perl.com/pub/a/2000/10/23/soto2000.html
be there: http://www.csse.monash.edu.au/~damian/papers/#Superpositions
Really.: http://developer.apple.com/techpubs/mac/PPCSoftware/PPCSoftware-13.html
To install Make, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Make
CPAN shell
perl -MCPAN -e shell install Make
For more information on module installation, please visit the detailed CPAN module installation guide.