2010年4月に出るのは……

先日，いわゆるPerl 6の実装が2010年4月をめどにRakudo *（Rakudo Star）の名前でリリースされる，という記事が紹介されました。

そのネタ元となった記事を書いたパトリック・ミショー（Patrick Michaud）氏は，2009年4月17日のNordic Perl Workshopを皮切りに，2009年6月22日のYAPC|10（YAPC::NA⁠）⁠，2009年7月22日のOSCON，2009年8月4日のYAPC::EUと，立て続けにRakudoの発表を行い，そのまとめとして当該記事を掲載したのですが（ちなみにRakudo *の公開時期はすでにOSCONの時点で明言されていました⁠）⁠，その3日後にご本人によるフォロー記事が出ているように，この短い紹介記事では意図が伝わりにくい面もあったようです。

そこで，今回はRakudoとはどのようなもので，今回の発表がどんな意味を持つものだったのか，もう少し踏み込んだ説明をしてみようと思います。

Perl 6に至るまでの道のり

Perlは，もともとはawkやsedを駆使するシェルスクリプトとCのいいとこ取りを目指して生まれた言語でした。もちろん最初からそれほど多くのことができたわけではありませんが，その懐の深さから，1994年にPerl 5が出るまでには実に多くの機能が取り込まれてきましたし，Perl 4時代には少なからぬ数の分岐が存在していました。昔からのユーザであれば，日本人向けにマルチバイト処理を追加したjperlだけでなく，oraperlのようにデータベース固有のライブラリを加えたPerlなどがあったことも覚えておられることでしょう。

Perl 5では，このような状況を整理し，本体に新しい機能を追加するのではなく，外部モジュールを使って機能を拡張する方向に舵を切ります。その方針変更は非常にうまくいき，CPANはいまや7000人を越す作者が18000以上のディストリビューション，7万以上のモジュールを登録する巨大なネットワークに成長しましたが，たとえばスレッドやUnicode対応のように，本体に影響を与えるような修正が必要になる場面はまだ残っていました。そして，Perl本体のソースコードは複雑になりすぎて，何かを壊さずには新しい機能を追加できないような状態になっていました。

そこで，一度現在の実装については忘れて，次世代のPerlにふさわしい仕様を書くところから仕切り直そう，という話になったのが，Perl 6プロジェクトの発端でした。それが2000年のことだったのは，この連載でも何度か出てきた通りです。

その後，紆余曲折を経て，Apocalypse（黙示録）やExegesis（釈義⁠）⁠，そしてそれらをわかりやすく書き直したSynopsis（梗概）といった基本仕様が一通り出揃ったのが2004年のこと。翌2005年にはその仕様をもとに，オードリー・タン（唐鳳）氏が覚えたてのHaskellを使ってPugsと呼ばれる処理系を実装します。

Pugsがもたらしたもの

PugsはPerl 6の世界にさまざまなものをもたらしました。たとえば，Pugsそのものをテストするために大量のPerl 6コードが書かれたおかげで，まだ議論が尽くされていない仕様の漏れや，無理矛盾が指摘されるようになりましたし，実際に手を動かして試せる環境ができたことで，直接仕様の策定にかかわっていなかった開発者を引き込むこともできるようになりました。2005年5月には早くもIRC上で会話しながら実際にPerl 6のコードを試せるように，Perl 6製のevalbotが登場していますし，（⁠現在は利用できないようですが）2006年にはブラウザ上からPerl 6のコードを試せるようにWeb端末も用意されていました。Pugsのリポジトリには，いくつかのCPANモジュールの移植が試みられた痕跡も残っています。

要するに，いわゆる「Perl 6」は，仕様にしても，実装にしても，このときすでにあったわけです。

ただ，当時でさえPerl 1.0時代から数えて17年，Perl 5.0から数えても10年の蓄積があった現行の処理系に比べると，実装が始まったばかりのPugsはあきらかに足りないものだらけでした。そんな状態でうかつに「Perl 6が出た」と言っては，いたずらにPerl 6の評判を落とすだけです。

だから，誰もが口をぬぐって「⁠（⁠みんなが満足するような）Perl 6はいつかのクリスマスに」という話を繰り返しました。PugsがHaskellで書かれていたことも，その言い訳がもっともらしく聞こえる一因となったのでしょう。誰もが，プロトタイプでない，オフィシャルな「Perl 6」は別にあるはずだと思っていました。その根拠となったのが，Parrotという（言語向け）仮想マシンの存在でした。

瓢箪から駒

Parrotは，もともとは2001年の壮大なエイプリルフールのネタでした。詳しい顛末は仕掛け人であったサイモン・カズンズ（Simon Cozens）氏の記事をご覧いただくとして，簡単にいうと，Parrotは「Perl 6の設計に取り組んでいたPerl業界と，Python 3000の設計に取り組んでいたPython業界が，手に手を取り合って生み出した新しいP言語」という楽しい空想，のはずだったのです。

ところが，プログラミング言語を実装するための技術はこの数十年来大きく変わっていないことから，ベストプラクティスをまとめた汎用的な仮想マシンを用意すれば，Perl 6の実装に役立つだけでなく，将来的には（ネタにあがった）Pythonをはじめとする，ほかの言語の（再）実装にも役立つだろう，という見通しのもと，2001年9月には本当にParrotという仮想マシンのバージョン0.0.1がリリースされてしまいます。

以来，Parrotはさまざまな企業・団体の助成金を受けながら，2009年3月にバージョン1.0までたどり着き，いまは2010年に予定されているバージョン2.0目指して，月に1回，第3火曜日にリリースが続けられています（2009年8月18日には「TEH PARROTZ!」という名前のバージョン1.5.0がリリースされました⁠）⁠。

Perl 6でPerl 6を

そのParrotのリポジトリのなかには，ほかのさまざまな言語のリポジトリとともに，Perl 6という名前のリポジトリがありました。

このPerl 6 on Parrotの実装は，ミショー氏が関与した正規表現まわりなど，一部の機能についてはPugsを上回る出来を見せていたものの（実際，Pugsは2006年9月に自前のツールを用意するまで，このParrotの正規表現解析器を利用していました（※1⁠）⁠）⁠，全体的な開発のペースは当初期待されていたほど良好なものではありませんでした。

もちろんそこにはParrot側の実装の遅れといった問題もあったのですが，おそらくそれと同じくらい切実だったのが，Perl 5の開発言語であるC（や，そのマクロ集であるXS）を書ける開発者の数に比べて，Parrotの内部表現に通じている開発者の数が圧倒的に少なかったことでした（HaskellベースのPugsもまったく同じ問題を抱えていました⁠）⁠。

この問題を緩和するため，2007年にはPugsから派生したKindaPerl6（⁠「⁠Perl 6的ななにか⁠」⁠）や，Perl 6 on Parrotから派生したNot Quite Perl 6（⁠「⁠あまりそれっぽくないPerl 6⁠」⁠）など，Perl 6を実装するためのソースコード自体をPerl 6で記述するための，機能を限定したPerl 6の実装が立て続けに登場します。Perl 6 on Parrotの大部分は，このNot Quite Perl 6を利用して書き直されました。

ただ，このように実装が乱立すると，どうしても「開発リソースを一箇所に集中してさっさと『Perl 6』を完成させるべきだ」という議論が出てきます。

2008年1月に登場したRakudoは，ある意味ではその問題を解決するために生まれたといってもよいのかもしれません。

※1

http://pugs.blogs.com/pugs/2006/09/pcr_replaces_pg.html