Delphiコンパイラの将来

By: Tomohiro Takahashi

Abstract: この記事は、Delphiコンパイラの状況と今後の概要について説明するものです。

    はじめに

この記事は、すべてのDelphiユーザーの皆さんに、私たちがDelphiコンパイラについて作業していることと検討している内容を知っていただくことを目的としています。エンバカデロの米国本社は、DelphiユーザーがどれだけDelphiコンパイラに愛着を持っているかを理解しており、私たちの研究開発部門では、クールな言語やいくつかのコンパイラ技術が誕生しつつあります。そこで、Delphiユーザーが愛するこのコンパイラの今後について、最新の情報をお伝えしたいと思った次第です。

    コンパイラの歴史

先にDelphiコンパイラの歴史について少し触れさせてください。そのほとんどは、おそらく皆さんにとって新しいことではありませんが、思い出して頂きたい重要な内容です。まず、Delphiコンパイラにはとても長い歴史があります。これ自体、Delphiコンパイラが高速でモダンなツールであり続けたことを証明しています。また、ジェネリクス/無名メソッド/インラインなどの数多くの先進的でモダンな機能をDelphiユーザーに提供してきました。しかし、過去の豊富な資産を引き継いで来たために、今でもコンパイラの中には昔のTurbo Pascal時代(とてつもなく古い時代)のコードがいくらか存在しています。多くのユーザーがおそらくその存在すら知らなかったであろう言語機能や構文もなお散在しています。例えば、今でも「(*...*)」でコメントを作成できることをどれだけのユーザーが知っているでしょうか?あるいは、以下のコードが今でもコンパイル可能であることをどれだけのユーザーが知っているでしょうか?

var
  WeirdLookingArray: array(.1..10.) of string;

いかがでしょうか。このことを知っているユーザーはそれほど多くはないでしょう。

いずれにしても、Delphiコンパイラは、後方互換性を維持するために、これらの構文やさまざまな機能をサポートし続けています。「後方互換性」は、ユーザーにとって「極めて重要な」ものですし、そして私たちにとっても「極めて重要な」ものなのです。これは重要なことです。後方互換性は、ユーザーにとって極めて重要なものですし、そして私たちにとっても極めて重要なものなのです(イタリックで記述した部分は、強調してお伝えしたいメッセージです)。しかしながら、ユーザーの大部分は、もはやそれらの機能の中の多くを使用していません。にもかかわらず、私たちはコンパイラをリリースするたびにそれらの機能を保守、テストし、動作保証し続けています。これは膨大な作業です。恐らくですが、すべてのユーザーはコンパイラの全機能は利用していないのですから(「括弧とピリオド"の件は知っている」といっていただく必要はありません。実際多くの開発者がそれを知らず、実際使われていないと考えています)、多くのユーザーが利用しない機能に対して作業する結果になってしまっています。あまり利用されない言語機能をサポートするということは、新しい言語機能のために割くことのできる時間を削ることになります。

上記の例は、あくまでも一例です。しかし、それらの古いコードセマンティクスの大半は、Delphi言語を改良してモダンなものにする上での障壁となっている機能であることも事実です。先に進む前にはっきりさせておくべきことは、ここでは、機能を削除することについて話をしようとしているのではなくて、単に、Delphi言語が今抱えている問題について語ろうとしているだけだということです。私たちには、何らかの言語機能を削除したり、ユーザーコードとの互換性がなくなるような計画は考えていません。もう一度言いますが、私たちにはそのような計画はありません。そうではなくて、むしろ、新たな興味深い計画があるのです。

    そういうわけで…

さて、そういうわけで、私たちは特に次のことを長期にわたって真剣に検討してきました。まず、どうすれば私たちのモダンで強力なコンパイラの持つ能力すべてを維持しながら、コンパイラを進化させることができるだろうか?そして、どうすれば既存のコードの動作を保証しながら、同時にコンパイラにクールで新しい機能を追加して進化させることができるだろうか、と。

いずれにせよ、この質問に対する答えは簡潔なものではなく、そう簡単に答えられるものでもありません。ましてや、私たちが軽々しく論じられる事柄でもありません。たしかに、コンパイラのフロントエンド全体を作り直して、私たちが欲している機能を持った新しいコンパイラを開発することもできたでしょうし、それに伴って多くの既存のコードとの互換性をばっさり捨てることもできたでしょう。しかし、そのような計画はいいはずがありません。本当に馬鹿げたことです。私たちは決してそのようなことを望んでいません。繰り返しになりますが、ユーザーの既存のコードが動作しなくなるような計画もありませんし、そのような意図もなければ、そうしなければならない理由もないのです。

ただ、私たちが行いたいと思っている内容というのは、Delphiがネイティブコードの開発分野(さらに言えば一般的な開発全般)において最先端をリードし続けられるようにするために、継続してDelphiを進化できるようにしていくということです。しかしときには、過去から引き継いできた事柄によって、進化が妨げられることがあります。Delphiは、非常にタイプセーフな言語ですが、完璧にタイプセーフというわけではありません。ユーザーは依然として、GetMem関数の呼び出しや、境界のない配列(array[0..0] of integer)の作成などを行えますし、参照といったものを利用してメモリを直接操作するなどのあらゆる危険な行為も行えます。そのようなことが行えるというのは強力な機能ではありますが、裏を返せばその動作の内容について説明しづらいということでもあります。そのため、コンパイラに期待した動作が得られないこともあります。多くの場合は期待する動作が得られることもありますが、これは「自分で自分の足を撃ち抜く」可能性があるということを示す主要な例です。Delphiはユーザーをシートベルトなしで乗せることができます。しかし、ユーザーがそういった行為を行えるという事実は、Delphi自身には行うことができない行為があるということを意味しています。もし、立派な3点ハーネスのシートベルトにフル装備のエアバッグが付いたクールなスポーツカーを運転できるとしたら、それは素敵なことではないでしょうか? もし、コンパイラがそうなったらどうでしょう?

    コンパイラのフロントエンド

通常コンパイラは、一般的に「フロントエンド」と呼ばれるものを搭載しています。このフロントエンドはコードを受け取って解析し、そのプログラムが意図している内容を表すツリー構造を作成します。ここが言語のシンタックスを理解する役割を果たしており、詰まるところこれこそが言語とは何なのかを定義しているのです。Delphiの場合はそのフロントエンドが、ユニット/forループ/begin,endの組/変数宣言/ジェネリッククラスなどの「Delphi構文一式」を理解する機能を有しています。また、そのフロントエンドは「DCUファイル」を生成しますが、そのDCUファイルは現時点ではコンパイラ依存になっています。このフロントエンドは、上述した歴史的な構文すべてを処理する役割も果たしています。それで次のような疑問が出てくるわけです。どうすれは、貴重な既存コードの動作を保証しながら、Delphiのフロントエンドに新しくてモダンな言語機能を追加できるだろうか、と。

もし私たちが、「従来のものとは違う新しい構文」と「従来の構文」のいずれかをユーザーが選択できるコンパイラフロントエンドを開発するとしたらどうでしょうか? (ここでもう一度、論旨を整理させてください。私たちは、言語機能を削除しようと言っているのではありません。仮にユーザーの方が、「それで、どの言語構文を非推奨にしようとしているのですか?」といった質問をコメントに書いたとしても、私は次のように答えます。「そのようなことはありません。ユーザーの既存のコードは動作し続けます」。これでもう明確になりましたよね?)あるいは、新しい手法として、既存のコードと「新しい」コードの双方が動作するようにするというのはどうでしょうか?これなら、既存のコードは以前とまったく同じように動作しつつ、新しいコードは新しいモジュールへ記述することが可能になります。既存のコードを新しい方式のモジュールへ組み入れることも可能でしょうが、もし仮に「その改善された新しい機能」を利用したいと思ったら、それは新しい形式のコードモジュールの中に記述しなくてはいけませんよね?そして、もし、コンパイラのバージョンに依存しないDCUフォーマット(今日のDCUファイルに似たものです)を開発することになったとしたらどうでしょうか?以上のことをどのように思われますか?

これは、私にはとても魅力的に感じられます。もちろん、そのような内容を実現するのは容易なことではありませんし、膨大な時間と労力を必要とするでしょう。しかし、これは非常に有益なことではありませんか?

だたし、このフロントエンドの問題は今回の論点の半分を占めているに過ぎません。コンパイラにはバックエンドというものも存在しているのです。

    コンパイラのバックエンド

コンパイラの専門家でない方のために補足すると、コンパイラの「バックエンド」とは、フロントエンドが生成した内容を読み込んで、マシンコード(機械語)を実際に出力する役割を果たすものです。これにより、必要なバイナリや、ある種のランタイム環境にとって有効なものを生成します。私たちのDelphiコンパイラおよびC++コンパイラは、現時点ではWindows向け32bitバイナリを生成します。しかしもちろん、バックエンドが現在のように32bitやWindowsに限定されるべき理由はありません。

私たちのバックエンドに求めている新しい機能の1つに、64bitバイナリを生成することがあります。そして、64bitバイナリを生成するには新しいバックエンドが必要になるでしょう。私たちは、単に既存の32bit向けバックエンドを改造して64bitに対応させ、それをユーザーに提供することもできました。しかし、そういう方法は適切なものではないでしょう。とりわけ、私たちのC++コンパイラおよびDelphiコンパイラが現時点では別々のバックエンドを使用しているということを考えればなおさらです。一度行えば済む作業を、なぜ二度も行う必要があるのでしょう?そしてもちろん、64bit化に関わるプロジェクトはコンパイラだけにとどまりません。ユーザーが64bitアプリケーション開発を何の制限もなく行えるようにするためには、デバッガ/エディタ/ファイルシステム/リファクタリング/モデリング/ドキュメントなどのあらゆる機能を完全に64bit対応させる必要があるのです。これには時間がかかります。

それよりも正しい対応方法とは、新しいバックエンドを開発することでしょう。仮に皆さんが新しいバックエンドを作ろうとした場合には、DelphiとC++Builderの双方で利用可能な単一のバックエンドを作成するというのが適切な選択でしょう。そしてその作業を行おうとする場合には、バックエンドが実際に対象とするプラットフォームはもちろんのこと、バックエンドにより柔軟性を持たせたアーキテクチャを採用することを望むでしょう。どうです?面白い考えだと思いませんか?

DelphiとC++Builderの両方に一度に対応した、統合されたバックエンドを全く新規に開発することは価値があることです。しかしそれには時間が必要です。多くの時間を要しますが、すぐに実現できることではありません。詰まるところ、適切な作業を行って、DelphiとC++Builderがともに恩恵を受けられるようなコンパイラアーキテクチャを開発するには、たいへんな努力が必要です。この開発を成功させることは私たちにとって重要なことですが、それがユーザーにとっても重要であるとは言い切れません。

興味深い事として、この新しいバックエンドを開発し、64bit対応製品をリリースするのに必要な期間のおかげで、Delphiのフロントエンドを新しくするチャンスが私たちに与えられました。それゆえ私たちは、バックエンドのために必要なすべての作業に時間を割くことを決断し、それによってフロントエンドにも興味深い機能を入れることができるようになりました。私たちは、既存のものを小手先で改良し、それをユーザーに提供しようとしているのではありません。私たちは、非常にクールなコンパイラを開発しようと思っています。ユーザーの皆様も、そう思って頂けると考えています。

Delphiは今、変革の時を迎えています。またこの変革は、私たち(そして、究極的にはユーザー)に真の変革を与えてくれる可能性を秘めています。

    最終的な結論

さて、この最終的な結論です。ようやく、今回の要点に辿り着きましたが、新しいバックエンドと64bit版コンパイラに対して行われているいくつかの主要な作業は、この新しいコンパイラアーキテクチャへと「移行」する絶好のタイミングだと思われます。私たちは、2010年の中頃には64bit対応版のDelphiをリリースすることを予定しています。コンパイラは、64bit完全に対応した製品を開発する上での最初のステップですので、私たちは2009年の中頃に64bit版のコンパイラのプレビュー版をリリースすることを計画しています。64bit対応のDelphiのリリースを心から待ち望んでいるユーザーは、そのコンパイラをいち早く試すことができます。

私たちは、これが変革であることを承知しています。しかし私たちは、次のことを信じていますし、ユーザーの方々も同意して頂けることを望んでいます。つまり、「Delphiがコンピュータ言語テクノロジーの最先端をリードし続けられるよう、非常にクールな変革を起こしてそれを成功に導くというのは、それだけの時間を費やす価値がある」、と。時間を費やして新しいコンパイラをいったん開発してしまえば、その後は多くのクールで新しい機能を追加することが可能になるはずです。ユーザーの皆さんも、きっとそういったクールで新しい機能を気に入っていただけますよね?

    まとめ

Delphiの進化を止めることはできません。C++Builderの進化を止めることもできません。私たちのコンパイラの進化も止めることはできないのです。進化を続けるには、コンパイラは開発者が望んでいるモダンで新しい機能を取り込まなくてはなりません。DelphiコンパイラもC++Builderのコンパイラも、ユーザーが現在、そして将来待ち望んでいるソリューションを提供しなければならないのです。そのような新しい機能を提供するためには、ことわざにもあるように、私たちはオムレツを作るためには、まずタマゴを割らなくてはならないのです。

しかし、ユーザーの皆さんの手元には、継続して動作させなければならない何兆億行ものコードが存在します。私たちはそのことをしっかりと認識しています。それゆえ、私たちは、ユーザーの皆さんの既存コードが動作し続け、DelphiとC++Builderを使用して64bitバイナリを出力でき、そしておそらくその他のバイナリも出力可能な、「新しいDelphi」と新しいコンパイラアーキテクチャを開発する作業を行っているのです。そして、それをユーザーの皆さんに提供できるよう、何としても成功させなければならないと思っています。

ご理解いただけましたでしょうか?以上が、私たちが計画している内容です。

Server Response from: ETNASC03