タイトル

Synopsis 1： Overview

著者

Larry Wall <larry@wall.org>

機種

Created: 10 Aug 2004

Last Modified: 31 Dec 2009
Version: 8

このドキュメントは元来初期の設計コンセプトをカバーする Apocalypse 1を要約した。そのオリジナルの要約は下に「ランダムな考え」の下に見いだされるかもしれない。しかしながら、これらの Synopses は「歴史のドキュメント」としてやがての長い間、氷のように冷たい Apocalypse と異なった Perl 6 の進化するデザインを反映するために同じく更新を含む。これらの更新は記録されていない－もし Synopsis がその Apocalypse と共に不一致であるなら、 Synopsis が正しいと想定しろ。

もう1つの仮定が、もし我々がこれらの Synopses に何かについて話をしないなら、それがそれが Perl 5 にあると同じであるということだった。まもなくけれども我々は Perl 5 の細部でギャップを埋めることを計画する。

プロジェクト計画書

主として、我々は巣に向かって（平均して）食物を輸送するためにすべて（まあ言わば）協力してただ1群のアリに過ぎない。種々のビットについて働いている人々の多くのグループがある、そして、これが主にボランティアの努力だから、それらとしての小片が適切と見る。

このドキュメントはこれらすべての subprojects を要約しようと試みない－このような情報のために http://perl6.org を見ろ。我々がここで言うことができることは、それが Perl 5 と一緒であった方法と異なり、これらのプロジェクトのいずれも Official Perl であるよう設計されないということだ。 Perl 6 は公式のテストセットをパスする何もだ。 Perl 6 のレベルが高い意味規則を探検することにおいて、そのプロジェクトが最も進んでいる1ポイントであったから、このテストセットは Pugs プロジェクトの下で初めに開発された。（他のプロジェクトはスピードあるいは互換性のような、他のことがより得意であるかもしれない。これは素晴らしい；すべての実装が等しくすべてが得意であることは必要じゃない。）公式のテストセットは夫婦共有財産であって、そしてプラットホームニュートラルであるように意図される、それで Perl 6 は、歴史の偶然によってではなく、その望ましい意味規則によって主に定義される。

もう1つのこれの様相が Perl 6 コンパイラが self のホストとして機能するだろうということだ。すなわち、種々のコード生成バックエンドが取って代わることができるという点に至るまで、コンパイラは最終的に、少なくともダウンしていて、それ自身をコンパイルするだろう。これは主としてプラットホーム依存を frontend から取り除く、それでただバックエンドだけがプラットホームに特定された問題のことで心配する必要がある。

けれどもとりわけ、我々のプロジェクト計画書はただ人々が見い出すのに役立つことだそれらはそれらがのような感じがすることができるスポット未来の（人たち・もの）を列している、（彼・それ）ら自身のためにもそして他の人たちのためにも共に. この辺りに、それは我々が楽しみと呼ぶものだ。

ランダムな考え

単語「全壊」は歴史的にただ「明らかにすること」だけを意味した、そして我々はその面白くないセンスでそれを使っている。
もしあなたが一般大衆から RFC を求めるなら、人々が極地のポジションに張り込む傾向があるから、あなたは多くの面白いが、矛盾したアイデアを得る、そして理念のいずれもお互いの上に形成されることができない。
Larry の First Law of Language Redesign ：皆がコロンを欲する。
RFC が「PSA」の上に評価されている：それらか否かにかかわらず、実数の外に問題、それらが実行可能な解決を提供するかどうか、そしてその解決が Perl 6 の地域として受け入れられる可能性が高いかどうか向けろ。
言語が乱暴にあなたが新規ユーザに言葉を提出するであろうと同じオーダーでデザインを変更されるべきだ。
Perl 6 はそれが想像上の完ぺきな言語、 Perl 7に発展することができるほど十分従順であるべきだ。この darwinian 命令形は下に上記の多数のシンタクスと多数のプラットホームに対するサポートを暗示する。
多くの詳細が変化するかもしれない、しかし Perl の本質は変化していないままでいるだろう。 Perl は multiparadigmatic であり続けるだろう、コンテキストに敏感な言語。我々は Perl を他のいかなる存在する言語にも変えていない。
移住は重要だ。 perl インタプリターは、コードが「クラス」あるいは「モジュール」キーワードで始まらないなら、それが Perl 5 コードを与えられていると想定するだろう、あるいはあなたは特にそれにあなたが通り過ぎてのような、何か他の方法で Perl 6 コードを走らせていると教える：
```
#!/usr/bin/perl6
use v6.0;
v6;
 
```
同じく、ファイルで.p6 拡張が示唆的であると思われるかもしれない、けれども数値を含んでいる他のいかなる拡張でもそうするかもしれない6そんなものけれどもp6l あるいはp6m あるいはpl6 あるいはpm6. 　（けれども.pl そして.pm まだ完全に受容できる拡張は Perl - 6 - ness が示される限り他の指標の1つか。）
他の方向での移住は同じく重要だ。 6モード、1（人・つ）がそれと共に後部を Perl 5 モードに落とすことができる Perl にuse v5 語彙のブロックの始まりに。このようなブロックはネストされるかもしれない：
```
use v6;
# ...some Perl 6 code...
{
    use v5;
    # ...some Perl 5 code...
    {
        use v6;
        # ...more Perl 6 code...
    }
}
 
```
フルの Perl 5 インタプリターを含むことが好都合じゃないとき、若干のプラットホームがこれを Perl 5 のサブセットに制限するかもしれない。標準的な Perl 6 文法はそれ自身のものの上に（PPIがそうするように極めて） Perl 5 の行儀が良いサブセットを解析する能力を含むだろう；実装がただ、もちろんそれらが同じく「バグためのバグ」互換性を実装することに決めるかもしれないけれども、このサブセットをサポートするように要求される。
基準化は Perl が multiparadigmatic である必要があるそれらの区域の1つとコンテキスト重要だ。 Perl 5 はデフォルトまでにではないを厳格であると分類する、他方 Perl 6 コードがそうだ。けれどもそれはリラックスすることが容易であるべきだ-e あるいはそのままのバージョン番号が：
```
perl -e '$x = 1'

#!/usr/bin/perl
v6; $x = 1;
 
```
ユーザーのために他のモジュールを呼び出すポリシー metamodules を書くことは可能に違いない。
もしあなたが Perl 6 にすべてをオブジェクトとして扱うことを望むなら、 Perl はあなたがそれをするのを手伝うだろう。もしあなたがすべてをオブジェクトとして扱うことを望まないなら、 Perl は同様にその観点に関してあなたの手助けをするだろう。
演算子はただ面白い名前を持った関数と構文に過ぎない。
言語デザイナーはまだ筋が通った全体の中に無関係な考えを総合するために必要だ。
言語デザイナーは全知でも、そして全能でもなくて、そして決して、要請にもかかわらず、それらの特定の特徴のためじゃないだろう。そのためにデザインプロセスはらせん状で、協力的、そして convergent だろう。集合のレートは新興のプロパティであって、そして強制されて、ただ奨励されることができない。誰でも何に関してでもそれをテストに従わせる Perl 6 の実装を不法アクセスしている限り、それをするテストスイートに関するセット、あるいはハッキングが仕様の合意を示す、集合のレートは肯定的であるとみなされるだろう。もしあなたが集合の電流率が気に入らないなら、どうかもっとあなたが集合に興味を持っていると思うほかの誰かに協力してくれ。
仕様は早々に凍りつかないだろうだろう、しかし種々の実装で、それの種々の局面が証明される（とき・から・につれて・ように）、固まる（あるいは disproven し）続けるだろう。仕様の多くの部分がすでに効果的に氷のように冷たいか、あるいはぬかるんだステートにある。「未来はすでにここでだ、それはただ不公平に配布される。」
証明されていないすべての speccedな特徴は実装で、たとえそれほど記録されていないとしても、いくぶん推測であると見なされるべきだ。実装が何が実際的であるか、そして何のではないかに関して合意に達し始める（とき・から・につれて・ように）、もし現在 speccedな若干の特徴が未来のバージョンに延期されているかもしれないなら、驚くな；これらはまだ長い間に Perl 6 の進展での長期的方向性だと見なされるべきだ、そして、その長期の進展を維持することにおいて、短期のデザインは保守的になるべきだ。たとえそれが進歩の錯覚をするであろうとしても、仕様について我々が何でも区分する延期するべき急ぎにいないことに注意を払え。我々が閉じである実装を仕様にもっていく（とき・から・につれて・ように）、仕様と実装の集合が当然起きるだろう。最初の実際的な実装が主としてどの特徴が6.0.0に必要とされると見なされるか決定するであろうことは非常にありそうだ。
皆が1度パニックを起こすことを可能にされる。しかしながら、絶え間がないパニックが有害であるとみなされるだろう。たとえそれらが特別な取り扱いが成功に必要であると思うとしても、誰も特別な取り扱いを得ない。これはあなたを意味する。