The heart of Parrot is a grandiose idea that turned out to be more realistic than anyone originally could have believed: why not have a single interpreter for several languages? Before this question was asked, dynamic languages such as Perl, Python, Ruby, and Scheme had all had their own individual interpreters; most of which were not easily extensible, not modular, and not capable of interoperation. The solution, it was decided, was to create a single virtual machine for all such languages. That virtual machine is called Parrot.
On April 1st, 2001, Simon Cozens published an article titled "Programming Parrot" as an April Fools' joke (http://www.perl.com/pub/a/2001/04/01/parrot.htm). It contained a contrived interview with Larry Wall and Guido van Rossum detailing their plans to merge Python and Perl into a new language called Parrot. This was a plausible ruse because both languages were undergoing massive redesigns: The Perl community was laying the groundwork for the next version, "Perl 6", and the Python team was working hard on a spec for "Python 3000". The Perl 6 project started moving in two different directions at once: the underlying interpreter architecture and the language grammar and semantics. As people realized that the two projects could become completely indepent, it was decided to create a proper language-agnostic virtual machine to support the high-level efforts. The virtual machine was later dubbed "Parrot" in a fitting turn of life imitating art.
The goal for the Parrot project was to create a language-neutral runtime environment for dynamic languages like Perl and Python. Of course, these two languages weren't the end, not for the Parrot team. They were thinking big. Parrot would have to support all the features other dynamic languages such as Ruby, Scheme, Befunge, PHP, and others. Threading and Unicode would be supported from the start, mitigating two thorns that had plagued Perl 5 developers for years. A robust exceptions system, a capability to compile into platform-independent bytecode, and a clean extension and embedding mechanism would be just some of the necessary and standard features. Parrot needed to have more then any of these languages had ever had by themselves, and it needed to do all these things right.
The irony is that the language-neutrality of the interpreter was originally just a side effect of good design. Keeping the implementation independent of the syntax would make the codebase cleaner and easier to maintain. Plus, the Parrot team could get to work long before the Perl 6 group even had their plans written.
Since Parrot would support the features of the major dynamic languages and wasn't biased to a particular syntax, it could run all these languages with little additional effort. It's generally acknowledged that different languages are suited to different tasks, and picking which language to use in a large software project is a common planning problem. There's never a perfect fit, at least not for all jobs. Developers find themselves settling for the language with the most advantages and the least noticeable disadvantages. The ability to easily combine multiple languages within a single project could be a huge benefit to developers. Before Parrot, language interoperability was a feature typically reserved for compiled languages such as C. Using well-tested libraries from one language, taking advantage of clean problem-domain expression in a second, and using languages according to their inherent strengths is the ultimate goal, one which the Parrot team is hoping to make a reality.
Modular design also benefits future language designers, not just designers of current languages. Instead of targeting lex/yacc and reimplementing low-level features such as garbage collection and dynamic data types, designers can leave the details to Parrot and focus on the high-level features of their language: syntax, libraries, capabilities. Parrot does all the necessary bookkeeping, exposing a rich interface with capabilities that few languages can make full use of.
As is typical of open source development projects, managing the development of Parrot is quite different from managing a commercial project of the same size and complexity. There are no schedules, no deadlines, no hiring and firing, and no salaries, bonuses, or stock options. There are no employees or bosses; there is very little hierarchy whatsoever. Management in this context isn't about giving orders, it's about making sure everyone has what they need to keep moving forward. Like most open-source and open-content projects, the best leadership is to set a good example and stay out of the way.
The Parrot development team is broken down into several distinct roles, which people assume according to their merits and their talents. This is a list of those roles, with a partial list of the folks who have taken responsibility for them.
The architect has primary responsibility for setting overall direction of the project, and to facilitate team communication and understanding of architectural issues. The architect is primarily, but not solely, responsible for making design decisions and documenting them in Parrot Design Documents ; responsibility for design and documentation of project subcomponents may be delegated to other members of the Project Team, or may be held jointly. The Architect also works with the Release Managers to develop and maintain the release schedule. Allison Randal currently leads the Parrot project aschief architect.
Release managers have responsibility for executing a product release according to the release schedule. The release schedule is developed and maintained jointly with the project Architect.
Current release managers are, in this order:
Jerry Gay X<Gay, Jerry> Patrick Michaud X<Michaud, Patrick> Matt Diephouse X<Diephouse, Matt> Will Coleda X<Coleda, Will> chromatic X<chromatic> Allison Randal X<Randal, Allison>
Information on the release procedure can be found in docs/project/release_manager_guide.pod. Parrot releases a stable version, under the direction of one of these release managers, every month.
All Metacommitters are responsible for managing commit access to the Parrot repository. Once the Architect or Pumpking approves a request for a contributor to be given commit access, a Metacommitter performs the necessary magic to give the new committer access to the SVN repository and the bugtracker. The Architect is a Metacommitter, but other Project Team members may also hold this role.
Current metacommitters are:
Allison Randal X<Randal, Allison> Chip Salzenberg X<Salzenberg, Chip> Jerry Gay X<Gay, Jerry> Will Coleda X<Coleda, Will> Jesse Vincent X<Vincent, Jesse>
The procedure on how to manage the list of Parrot committers can be found in docs/project/metacommiter_guide.pod.
Contributors who submit numerous, high-quality patches may be considered to become a Committer. Committers have commit access to the full Parrot repository, but generally work only on one or more subprojects; Committer categories are described below. Contributors may considered for commit access either by being nominated by another Committer, or by requesting it.
Core Developers develop and maintain core subsystems such as the IO subsystem, the exceptions system, or the concurrency scheduler.
Compiler Develoeprs develop and maintain one or more Parrot front-end compilers such as IMCC, PIRC, PGE and TGE.
Developers who work on any of the high-level languages that target Parrot such as TCL, Lua or Perl 6, are High-Level Language Developers. Many of these language projects are located in the Parrot repository, although some are maintained in separate locations. It is the intention that all languages be developed separately from Parrot before the 1.0 release.
Build Managers maintain and extend configuration and build subsystems. They reviews smoke reports and attempt to extend platform support.
Developing, maintaining, and extending test suite coverage and testing tool are the key tasks for the Lead Testers. Lead Testers are also responsible for testing goals, including complete coverage of core components on targeted platforms.
Hackers and developers submit patches to Parrot every day, and it takes a keen eye and a steady hand to review and apply them all. Patch Monsters, as they are affectionately known, are in charge of checking patches for conformance with coding standards and desirability of features.
A list of committers that have a role they've taken responsibility for can be found in RESPONSIBLE_PARTIES.
Parrot's cage, the development working environment, has a tendency to get messy and disorganized over time. It's the responsibility of the aptly-named Cage Cleaners to ensure coding standards are followed, that documentation is complete and accurate, that all tests are functioning properly, and that there are plenty of coding examples for new users to learn from. A class of tickets in the RT tracking system has been created especially for use by this group. This position encompasses tasks that run the gamut from entry-level to advanced, and is a good entry point for new users who want to get more familiar with Parrot internals.
Contributors are volunteers who write code or documentation patches, take part in email or online conversations, or contribute to the project in other important ways. All volunteer contributions are appreciated and recognized, with their names being added to the CREDITS file in the Parrot repository. When a new contributor submits patches which have been accepted, they should add their name to this list.
The list of general contributors can be found in CREDITS.
Last, but not least, is the glue that holds the project together. Bjørn Hansen and Robert Spier manage the email, revision control, and bug-tracking systems, as well as the web sites for Parrot, http://www.parrot.org and now http://www.parrot.org. Without these systems, the project would grind to a screeching halt.
In the end, it is the developers themselves who hold the project together. Individuals bear their own share of responsibility for finding tasks that suit their skills, coordinating with others to keep duplicated effort minimal, and ensuring that the job gets done.
Mailing lists are an important tool for communication, and the Parrot Development team maintains a special-purpose mailing list to coordinate the efforts of the many team members. The mailing list for Parrot is called "Parrot-Porters", and you can subscribe to it by sending a blank email message to perl6-internals-subscribe@perl.org. The list is archived at http://www.nntp.perl.org/group/perl.perl6.internals and available via NNTP at nntp://nntp.perl.org/perl.perl6.internals. Despite the presence of the term "perl6" in the list name, the list is not used to talk about Perl 6. The name is just a historical throw-back to the time when the Perl 6 and Parrot projects were one and the same.
You can also read the Parrot-Porters list via Google Groups at http://groups-beta.google.com/group/perl.perl6.internals
Parrot information and documentation can be accessed on the web in a variety of locations. The following web sites should have all the Parrot information you need to get started:
http://www.parrotcode.org
http://dev.perl.org/perl6
http://bugs6.perl.org
http://pugscode.org
9 POD Errors
The following errors were encountered while parsing the POD:
A non-empty Z<>
Deleting unknown formatting code U<>
To install Parrot::PMC, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Parrot::PMC
CPAN shell
perl -MCPAN -e shell install Parrot::PMC
For more information on module installation, please visit the detailed CPAN module installation guide.