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? The plan for Parrot formed in bits and pieces over the period of a year.
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 was a contrived interview with Larry Wall and Guido van Rossum detailing their plans to merge Python and Perl into a new language called Parrot. A few months later, when Perl 6 internals began to take an independent path within the larger project, they dubbed the subproject "Parrot" in a fitting turn of life imitating art.
The plan for Parrot was to build a language-neutral run-time environment. It would support all the features of dynamic languages such as Python, Ruby, Scheme, Befunge, and others. It would have threading and Unicode support (two of the most problematic features to add into Perl 5 code) designed in from the start. It would support exceptions and compilation to bytecode, and have clean extension and embedding mechanisms.
The language-neutral interpreter was originally just a side effect of good design. Keeping the implementation independent of the syntax would make the code cleaner and easier to maintain. One practical advantage of this design was that Parrot development could begin even though the Perl 6 language specification was still in flux.
The bigger win in the long term, though, was that 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. Picking which language will be used in a large software project is a common planning problem. There's never a perfect fit. It usually boils down to picking the language with the most advantages and the least noticeable disadvantages. The ability to easily combine multiple languages within a project could be a huge benefit. Use well-tested libraries from one language for one task. Take advantage of a clean way of expressing a particular problem domain in a second, without being forced to use it in areas where it's weak.
The modular design also benefits future language designers. Instead of targeting lex/yacc and reimplementing low-level features such as garbage collection and dynamic types, designers can write a parser that targets the Parrot virtual machine.
As is typical of open source development projects, managing the Parrot project 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.
This is a list of project 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 design documentation of project subcomponents may be given to other members of the Project Team, or may be held jointly. The Architect also works with the Pumpking and Release Managers to develop and maintain the release schedule. Allison Randal leads the Parrot project as chief architect.
The Pumpking has primary responsibility for the project source. The Pumpking is the lead developer, and as such reviews patches, defines coding standards, and assists the efforts of Committers and Contributors. The Pumpking also develops and maintains the release schedule with the Architect and Release Managers. Chip Salzenberg is the current pumpking.
Release managers have responsibility for executing a product release, according to the release schedule. The release schedule is developed and maintained jointly with the Architect and the Pumpking.
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.
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 provides that access. The Architect and Pumpking are Metacommitters, 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 asking for it.
Develops and maintains core subsystems (e.g. IO, Exceptions).
Develops and maintains one or more Parrot compilers (e.g. IMCC, PGE, TGE).
Develops and maintains one or more High Level Languages (e.g. Tcl, Lua, Perl 6).
Maintains and extends configure and build subsystems. Reviews smoke reports and attempts to extend platform support.
Develops, maintains, and extends test suite and testing tools. Responsible for testing goals, including complete coverage of core components on targeted platforms.
Develops and maintains installation packages on various platforms.
Reviews and applies patches submitted by general contributors, keeping an eye on 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.
Fixes failing tests, makes sure coding standards are implemented, reviews documentation and examples. A class of tickets in the tracking system (RT) has been created for use by this group. This position encompasses tasks from entry level to advanced, and is a good way to get 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 ways. All volunteer contributions are appreciated and recognized. All volunteers who contribute to a file in the Parrot repository may add their name to the CREDITS file.
The list of general contributors can be found in CREDITS.
Last, but not least, is the glue that holds the project together. Ask Bjørn Hansen and Robert Spier manage the email, revision control, and bug-tracking systems, as well as the web site for Parrot, http://www.parrotcode.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 making sure the job gets done.
The mailing list for parrot is parrot-porters. Subscribe by sending mail to perl6-internals-subscribe@perl.org. It is archived at http://www.nntp.perl.org/group/perl.perl6.internals and available via NNTP at nntp://nntp.perl.org/perl.perl6.internals.
You can also read the list via Google Groups at http://groups-beta.google.com/group/perl.perl6.internals
The following web sites have all the Parrot information you need:
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::Op, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Parrot::Op
CPAN shell
perl -MCPAN -e shell install Parrot::Op
For more information on module installation, please visit the detailed CPAN module installation guide.