=head1 Title
Synopsis 1: Overview
=head1 Author
Larry Wall <[EMAIL PROTECTED]>
=head1 Version
Maintainer:
Date:
Last Modified:
Number: 1
Version: 0
This document summarizes Apocalypse 1, which covers the initial
design concept. (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.)
The other basic assumption is that if we don't talk about something in these
Synopses, it's the same as it was in Perl 5.
=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 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.
=item *
Scaling is one of those areas where Perl needs to multiparadigmatic and
context sensitive. Therefore your main code is allowed to be lax, while
module and class code is (by default) required to be strict.
=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.
=back
