Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.

The Continuing Mission

Much has changed since the early days of the project.
New people join and others leave in a regular
“changing of the guard” pattern.
Plans change as the work progresses, and the demands of the work and
the needs of the community become clearer. Today the Perl 6 project
has two major parts: language design and internals. Each branch is
relatively autonomous, though there is a healthy amount of
coordination between them.

Language Design

As with all things Perl,
the
central command of the language design process is Larry Wall, the
creator of the Perl language. Larry is supported by the rest of the
design team: Damian Conway, Allison
Randal, Dan
Sugalski, Hugo
van der
Sanden, and chromatic. We speak in weekly teleconferences and also
meet face-to-face a few times a year to hash out ideas for the design
documents, or to work through roadblocks standing in the way of
design or implementation. The design team is a diverse group,
including programmers-for-hire, Perl trainers, and linguists with a
broad spectrum of interests and experiences. This diversity has
proved quite valuable in the design process, as each member is able
to see problems in the design or potential solutions that the other
members missed.

Requests For Comments (RFCs)

The first step in designing the new language was the
RFC (Request For Comments) process.
This spurred an initial burst of community involvement. Anyone was
free to submit an RFC on any subject, whether it was as small as
adding an operator, or as big as reworking OO syntax. Most of the
proposals were really quite conservative. The RFCs followed a
standard format so they would be easier to read and easier to
compare.

Each RFC was subject to peer review, carried out in an intense few
weeks around October 2000. One thing the RFC process demonstrated was
that the Perl community still wasn’t quite ready to
move beyond the infighting that had characterized Perl 5 Porters
earlier that year.[1]
Even though few RFCs have been accepted without modification, the
process identified a large number of irritants in the language. These
have served as signposts for later design efforts.

Apocalypses, Synopses, Exegeses

The Apocalypses,[2]Synopses, and
Exegeses[3] are an
important part of the design process. Larry started the
Apocalypse series
as a systematic way of answering the RFCs. Each Apocalypse
corresponds to a chapter in his book Programming
Perl, and addresses the features in the chapter that are
likely to change.

However, the Apocalypses have become much more than a simple response
to 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 a solution 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 of it. But each Apocalypse also goes beyond a simple
“yes” and
“no” response to attack the roots
of the problems identified in the RFCs.

The Synopses are summaries of each Apocalypse. These act as a quick
reference for the current state of design, and are more approachable
than the often lengthy Apocalypses. The Synopsis series
didn’t start until Apocalypse 5, but Luke Palmer is
now working on the retroactive Synopses 2-4.

Damian Conway’s Exegeses are extensions of each
Apocalypse. The Exegeses are built around practical code examples
that apply and explain the new ideas.

The p6l mailing list

The next body of design work is the Perl 6 Language mailing list
(perl6-language@perl.org), often
fondly referred to as "p6l.”
Piers Cawley writes a weekly summary of all the Perl 6 mailing lists.
Luke Palmer has been deputized as unofficial referee of the list. He
answers questions that don’t require the direct
involvement of the design team or that have been answered before. The
list has approximately 40 regular contributors in any given month, as
well as a large number of occasional posters and lurkers. Some people
have participated since 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’s an open forum for any ideas on the
user-visible parts of Perl 6. In the typical pattern, one person
posts an idea and 5 to 10 people respond with criticisms or
suggestions. The list periodically travels down a speculative thread
like a runaway train, but these eventually run out of steam. Then
Larry picks out the golden bits and gently tells the rest that no, he
never intended Perl 6 to have neo-Vulcan mechanoid Scooby-Dooby-doos.
Even when Larry doesn’t post, he follows the list
and the traffic serves as a valuable catalyst for his thoughts.

Internals

The internals
development for Perl 6 falls to the Parrot project. 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? Unlike the parent Perl 6 project,
which was launched in a single day, the plan for Parrot formed in
bits and pieces over the period of a year.

On April 1, 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.

Early Steps Toward Perl 6 Internals

The earliest progress toward implementing Perl 6 started before the
current incarnation of Perl 6 was even conceived. The Topaz project,
started in 1998, was spearheaded by Chip Salzenberg. It was a
reimplementation of Perl 5 written in C++. The project was abandoned,
but many of the goals and intended 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 6 internals. It was a one-week project in September 2000. The
brainchild of Simon Cozens, Sapphire was another rewrite of Perl 5
internals. It was never intended for release, only as an experiment
to see how far the idea could go in a week, and what lessons could be
learned.

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.

Dan Sugalski leads the Parrot project as chief architect, and Leopold
Tötsch is the current
pumpking. The Parrot project is largely autonomous. Dan coordinates
with the rest of the design team to ensure that Parrot will be able
to support the semantics Perl 6 will require, but the language
designers have very little input into the details of implementation.
Parrot isn’t developed solely for Perl, but Perl 6
is entirely dependent on Parrot—it is the only interpreter for
Perl 6.

The core communication line for the Parrot project is the mailing
list, perl6-internals@perl.org,
otherwise known as "p6i.”
It’s a much more business-like list than p6l.
Workflow in Parrot takes the form of submitted patches. Anyone is
free to submit a patch, and contributors who consistently submit
valuable patches over a long period of time are granted check-in access to
the CVS repository.

Ponie

Ponie is an implementation of Perl 5 on Parrot, started in July 2003.
Offically, Ponie stands for
"Perl On New Internal
Engine.” The name was originally derived from a
running gag in the London.pm Perl Mongers group where the phrase
“I want a pony” appeared in lists
of feature requests for Perl (and other unusual places).

The project, led by Artur Bergman, has taken the Perl 5 source code
as a base and is gradually replacing the core elements with Parrot
equivalents. Legacy code will be one of the biggest obstacles to
projects considering the move from Perl 5 to Perl 6. Few companies
have the resources to do a complete update to existing code every
time a new version of the language is released. Ponie offers a smooth
migration
path that ensures Perl 5 code will function as long as
it’s needed. You’ll even be able to
use Perl 5 modules and Perl 6 modules side-by-side in the same
program. The current plan is for Ponie to be the 5.14 or 5.16 release
of Perl.

Supporting Structure

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 pages for Perl 6,
Parrot, and Ponie (http://dev.perl.org). Without these systems,
the project would grind to a screeching halt.

Allison Randal is the project manager. As is
typical of open source development projects, managing the Perl 6
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.

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.

[1] 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 tolerant
community of today, but it’s an accurate
representation of the time when it was written.

[2] An
“apocalypse” in the sense of
“revelation,” not
“end of the world.”