Perl 6 and the Parrot Project, Page 2
The Continuing Mission
Much has changed since the early days of the project. New people join thegroup and others leave in a regular “changing of the guard” pattern. Planschange as the work progresses, and the demands of the work and the needsof the community become clearer. Today the Perl 6 project has three majorparts: language design, internals, and documentation. Each branch is relatively autonomous, though there is a healthy amount of coordinationbetween them.
As with all things Perl, the central command of the language design processis Larry Wall, the creator of the Perl language. Larry is supported by the restof the design team: Damian Conway, Allison Randal, Dan Sugalski, Hugovan der Sanden, and chromatic. We speak in weekly teleconferences andalso meet face–to–face a few times a year to hash out ideas for the designdocuments, or to work through roadblocks standing in the way of design orimplementation. The group is diverse, including programmers–for–hire, Perltrainers, and linguists with a broad spectrum of interests and experiences.This diversity has proved quite valuable in the design process, as each mem-ber is able to see problems in the design or potential solutions that the othermembers missed.
Requests for comments (RFCs)
Each RFC was subject to peer review, carried out in an intense few weeksaround October 2000. One thing the RFC process demonstrated was thatthe Perl community still wasn´t quite ready to move beyond the infightingthat had characterized Perl 5 Porters earlier that year.*
*Mark-Jason Dominus wrote an excellent critique of the RFC process (http://www.perl.com/pub/a/2000/11/perl6rfc.html ). It may seem harsh to people accustomed to the more open and tolerantcommunity of today, but it´s an accurate representation of the time when it was written.
Even though few RFCs have been accepted without modification, the pro-cess identified a large number of irritants in the language. These have servedas signposts for later design efforts.
Apocalypses and Exegeses
The Apocalypses* and Exegeses** are an important part of the design process.Larry started the Apocalypse series as a systematic way of answeringthe RFCs. Each Apocalypse corresponds to a chapter in his book Programming Perl,and addresses the features in the chapter that are likely to change.
*An “apocalypse” in the sense of “revelation,” not “end of the world.”
**An “exegesis” is an explanation or interpretation of a text...
However, the Apocalypses have become much more than a simple responseto RFCs. Larry has a startling knack for looking at 12 solutions to a problem,pulling out the good bits from each one, and combining them into asolution that is 10 times better than any of the proposals alone. The Apocalypses are an excellent example of this “Larry Effect.” He addresses each relevant RFC,and gives reasons why he accepted or rejected various pieces ofit. But each Apocalypse also goes beyond a simple “yes” and “no” responseto attack the roots of the problems identified in the RFCs.
Damian Conway´s Exegeses are extensions of each Apocalypse. Each Exegesis is built around a practical code example that applies and explains thenew ideas.
The p6l Mailing List
The next body of design work is the Perl 6 Language mailing list (email@example.com), often fondly referred to as “p6l.” Luke Palmer has beendeputized as unofficial referee of the list. He answers questions that don´trequire the direct involvement of the design team or that have beenanswered before. He also keeps an eye out for good suggestions to makesure the design team doesn´t miss them in the sea of messages. The list hasapproximately 40 regular contributors in any given month, as well as a largenumber of occasional posters and lurkers. Some people have participatedsince the very beginning; others appear for a few months and move on.
Even though the individuals change, the general tone of p6l is the same. It´san open forum for any ideas on the user-visible parts of Perl 6.In the typicalpattern, one person posts an idea and 5 to 10 people respond with criti-cisms or suggestions. The list periodically travels down a speculative threadlike a runaway train, but these eventually run out of steam. Then Larry picksout the golden bits and gently tells the rest that no, he never intended Perl 6to have hyper–vulcan mechanoid scooby–dooby–doos. Even when Larrydoesn´t post, he follows the list and the traffic serves as a valuable catalystfor his thoughts.
Parrot is a grandiose idea that turned out to be more realistic than anyoneoriginally could have believed: why not have a single interpreter for severallanguages? Unlike the parent Perl 6 project,which was launched in a singleday, the plan for Parrot formed in bits and pieces over the space of a year.
On April 1,2001, Simon Cozens published an article titled “ProgrammingParrot” 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 vanRossum detailing their plans to merge Python and Perl into a new languagecalled Parrot. A few months later, when Perl 6 internals began to take anindependent path within the larger project,they dubbed the subproject“Parrot” in a fitting turn of life imitating art.
Early Steps Toward Perl 6 Internals
The earliest progress toward implementing Perl 6 started before the currentincarnation of Perl 6 was even conceived. The Topaz project, started in 1998,was spearheaded by Chip Salzenberg. It was a reimplementation of Perl 5written in C++. The project was abandoned, but many of the goals andintended features for Topaz were adopted for Perl 6 internals, and the difficulties Topaz encountered were also valuable guides.
Sapphire was another early prototype that influenced the shape of Perl 6internals. It was a one-week project in September 2000. The brainchild ofSimon Cozens, Sapphire was another rewrite of Perl 5 internals. It was neverintended for release, only as an experiment to see how far the idea could goin a week, and what lessons could be learned.
Page 2 of 3