
=encoding utf8

=head1 TITLE

Synopsis 1: Overview

=head1 AUTHORS

    Larry Wall <larry@wall.org>

=head1 VERSION

    Created: 10 Aug 2004

    Last Modified: 31 Dec 2009
    Version: 8

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.

=head1 Project Plan

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
L<http://perl6.org> 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 was at one point the furthest along
in exploring the high-level semantics of Perl 6.  (Other projects
may be better at other things, such as speed or interoperability.
This is fine; it is not necessary that all implementations be equally
good at everything.)  The official test suite is community property,
and is intended to be platform neutral, 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.

=head1 Random Thoughts

=over 4

=item *

The word "apocalypse" historically meant merely "a revealing",
and we're using it in that unexciting sense.

=item *

If you ask for RFCs from the general public, you get a lot of
interesting but contradictory ideas, because people tend to stake
out polar positions, and none of the ideas can build on each other.

=item *

Larry's First Law of Language Redesign: Everyone wants the colon.

=item *

RFCs are rated on "PSA": whether they point out a real Problem,
whether they present a viable Solution, and whether that solution is
likely to be Accepted as part of Perl 6.

=item *

Languages should be redesigned in roughly the same order as you would
present the language to a new user.

=item *

Perl 6 should be malleable enough that it can evolve into the imaginary
perfect language, Perl 7.  This darwinian imperative implies support
for multiple syntaxes above and multiple platforms below.

=item *

Many details may change, but the essence of Perl will remain unchanged.
Perl will continue to be a multiparadigmatic, context-sensitive
language.  We are not turning Perl into any other existing language.

=item *

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;

Also, a file with a C<.p6> extension may be taken as indicative,
as may any other extension containing the digit C<6>, such as C<p6l>
or C<p6m> or C<pl6> or C<pm6>.  (Though C<.pl> and C<.pm> are still
perfectly acceptable extensions as long as the Perl-6-ness is indicated
one of the other indicators.)

=item *

Migration in the other direction is also important.  In Perl 6
mode, one can drop back to Perl 5 mode  with C<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...
        }
    }

Some platforms may restrict this to a subset of Perl 5 when it is
not expedient to include a full Perl 5 interpreter.  The standard
Perl 6 grammar will include the ability to parse a well-behaved
subset of Perl 5 on its own (much like PPI does); implementations
are required only to support this subset, though of course they may
also choose to implement bug-for-bug compatibility.

=item *

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 C<-e> or
a bare version number:

    perl -e '$x = 1'

    #!/usr/bin/perl
    v6; $x = 1;

=item *

It must be possible to write policy metamodules that invoke other
modules on the user's behalf.

=item *

If you want to treat everything as objects in Perl 6, Perl will help
you do that.  If you don't want to treat everything as objects, Perl
will help you with that viewpoint as well.

=item *

Operators are just functions with funny names and syntax.

=item *

Language designers are still necessary to synthesize unrelated ideas
into a coherent whole.

=item *

The language designer is neither omniscient nor omnipotent, and never
will be, despite requests for those particular features.  Therefore
the design process will be spiral, cooperative, and convergent.
The rate of convergence is an emergent property, and cannot be forced,
only encouraged.  As long as anyone is hacking on any implementation
of Perl 6 to make it conform to the test suite, or hacking on the
test suite to make it reflect consensus of specification, the rate
of convergence will be deemed to be positive.  If you are unhappy
with the current rate of convergence, please cooperate more with
someone else you think is interested in convergence.

=item *

The spec will not be frozen prematurely, but will continue to solidify
as various aspects of it are proven (or disproven) in various
implementations.  Many parts of the spec are already effectively
frozen, or are in a slushy state.  "The future is already here,
it's just unevenly distributed."

=item *

All specced features that have not been proven in an implementation
should be considered somewhat conjectural, even if not so marked.
As implementations start to agree on what is practical and what is not,
do not be surprised if some features that are currently specced may be
deferred to future versions; these should still be considered long-term
direction in the evolution of Perl 6 over time, and the short-term
design should be conservative in preserving that long-term evolution.
Note that we are not in a hurry to defer any sections of the spec,
even if that would give the illusion of progress.  Convergence
of specs and implementations will happen naturally as we get
implementations that are closer to the spec.  It is quite likely
that the first practical implementation will largely determine
which features are considered to be required in 6.0.0.

=item *

Everyone is allowed to panic I<once>.  However, continual panic will
be deemed poisonous.  Nobody gets special treatment, even if they
think special treatment is necessary for success.  This means you.

=back

=for vim:set expandtab sw=4:
