Help-Site Computer Manuals
  Algorithms & Data Structures   Programming Languages   Revision Control
  Cameras   Computers   Displays   Keyboards & Mice   Motherboards   Networking   Printers & Scanners   Storage
  Windows   Linux & Unix   Mac


Synopsis_01 - Overview


Synopsis_01 - Overview


Larry Wall <>


  Maintainer: Larry Wall <>

  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:
        use v6.0;

  • 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'
        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.