=head1 TITLE

綱要之一：概論

=head1 AUTHOR

Larry Wall <larry@wall.org>

=head1 VERSION

  Maintainer: Luke Palmer <luke@luqui.org>
  Date: 10 Aug 2004
  Last Modified: 18 Aug 2004
  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.)

此份文件總結了啟示錄之一，涵蓋了最初的設計概念。（這些綱要也包含了
反映隨著時間而演化的 Perl 6 設計，而不像作為歷史文件的啟示錄，不會再更
動。這些更新不會被標示出來--如果綱要與其啟示錄有所抵觸，請假設綱要是對
的。）

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.

另一個基本的假設，是如果某樣東西沒有在這些綱要中提及，那就跟在 Perl 5 
中是一樣的。

=head1 Random Thoughts

=head1 隨想

=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.

如果你對一般大眾要求 RFC，你會得到一堆有趣但是互相抵觸的主意，這是因為
每個人的立足點都不同，使得這些主意都沒有辦法互為基石。

=item *

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

Larry 的語言重設計第一定律：每個都要冒號。

=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.

RFCs 是以 "PSA" 來評等的：是否它們提出實際的問題(Problem)，是否它們呈
現出可行的解決方案(Solution)，還有這個解決方案是否有可能被接受(Accept)
成為 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.

Perl 6 應該具有足夠的延展性，讓它可以進化成幻想中的完美語言 Perl 7。這
種達爾文天命暗示對上要支援多種語法，對下要支援數種平台。

=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.

多數的細節可能會有變化，但是 Perl 本質不會有所改變。Perl 仍然會是多典
範，注重語境的語言。我們不會把 Perl 變成其它現有的語言。

=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:

轉移是很重要的。perl 解譯器會假設它所收到的是 Perl 5 程式碼，除非程式
碼是以”class”或”module”關鍵字開始的，或是你很確定地以某種方式跟它
說要跑的是 Perl 6 程式碼，像是：

    #!/usr/bin/perl6
    use v6.0;
    v6;

=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 maybe
even a bare version number:

延展性是另一個 Perl 為什麼要是多典範與注重語境的地方。Perl 5 程式碼預
設並非嚴格語法，而 Perl 6 是。不過它可以很簡單地以 C<-e> 來放鬆，甚至
是單純的一個版本號碼：

    perl -e '$x = 1'

    #!/usr/bin/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.

如果你想要在 Perl 6 中將每樣東西都視為物件，Perl 會幫你作到。如果你不
想要把每樣東西都當作是物件，Perl 也可以幫你達到。

=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