Synopsis_01 - Overview

NAME

Synopsis_01 - Overview

AUTHOR

VERSION

  Maintainer: Larry Wall <larry@wall.org>
  Date: 10 Aug 2004
  Last Modified: 24 Oct 2005
  Number: 1
  Version: 3

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.

Random Thoughts

The word ``apocalypse'' historically meant merely ``a revealing'', and we're using it in that unexciting sense.
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.
Larry's First Law of Language Redesign: Everyone wants the colon.
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.
Languages should be redesigned in roughly the same order as you would present the language to a new user.
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.
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.
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;
```
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;
```
It must be possible to write policy metamodules that invoke other modules on the user's behalf.
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.
Operators are just functions with funny names and syntax.
Language designers are still necessary to synthesize unrelated ideas into a coherent whole.

Synopsis_01 - Overview