Synopsis 1: Overview
Larry Wall <larry@wall.org>
Maintainer: Larry Wall <larry@wall.org> Date: 10 Aug 2004 Last Modified: 30 Jan 2007 Number: 1 Version: 6
This document originally summarized Apocalypse 1, which covers the initial design concept. That original summary may be found below under "Random Thoughts". However, these Synopses also contain updates to reflect the evolving design of Perl 6 over time, unlike the Apocalypses, which are frozen in time as "historical documents". These updates are not marked--if a Synopsis disagrees with its Apocalypse, assume the Synopsis is correct.
Another assumption has been that if we don't talk about something in these Synopses, it's the same as it is in Perl 5. Soon we plan to fill in the gaps with the Perl 5 details though.
Mostly, we're just a bunch of ants all cooperating (sort of) to haul food toward the nest (on average). There are many groups of people working on various bits and pieces as they see fit, since this is primarily a volunteer effort.
This document does not attempt to summarize all these subprojects--see the various websites for Parrot and Pugs and Perl 6 for such information. What we can say here is that, unlike how it was with Perl 5, none of these projects is designed to be the Official Perl. Perl 6 is anything that passes the official test suite. This test suite was initially developed under the Pugs project because that project is the furthest along in exploring the high-level semantics of Perl 6. (Other projects are better at other things, such as speed or interoperability.) However, the Pugs project views the test suite as community property, and is working towards platform neutrality, so that Perl 6 is defined primarily by its desired semantics, not by accidents of history.
Another aspect of this is the Perl 6 compiler will be self-hosting. That is, the compiler will eventually compile itself, at least down to the point where various code-generating backends can take over. This largely removes platform dependencies from the frontend, so that only the backends need to worry about platform-specific issues.
But above all, our project plan is simply to help people find a spot where they can feel like they're creating the future, both for themselves and for others. Around here, that's what we call fun.
Migration is important. The perl interpreter will assume that it is being fed Perl 5 code unless the code starts with a "class" or "module" keyword, or you specifically tell it you're running Perl 6 code in some other way, such as by:
#!/usr/bin/perl6
use v6.0;
v6;
Migration in the other direction is also important. In Perl 6
mode, one can drop back to Perl 5 mode with use v5 at the
beginning of a lexical block. Such blocks may be nested:
use v6;
# ...some Perl 6 code...
{
use v5;
# ...some Perl 5 code...
{
use v6;
# ...more Perl 6 code...
}
}
Scaling is one of those areas where Perl needs to be multiparadigmatic
and context sensitive. Perl 5 code is not strict by default, while
Perl 6 code is. But it should be easy to relax with -e or
a bare version number:
perl -e '$x = 1'
#!/usr/bin/perl
v6; $x = 1;