プロ生ちゃんが聞く!

3 1月

久しぶりにtwitter以外で文章を書いたんだ。僕はキメ顔でそう言った。

プロ生ちゃんが聞く! 2014年プログラミング言語動向

さて、このインタビューで出てきたRoslynっていうものについて、少しフォローアップをしておきましょう。

コンパイラーは2つある

Roslyn以前のお話。あるいは、Roslynが解決する問題。

コンパイラーは2つ保守されています(C#に限った話ではなくて、例えばJavaなんかでも)。要するに、ソースコードをILやバイトコードに変換するためのものと、統合開発環境(IDE: Integrated Development Environment)がソースコード解析などに使うもの。

後者は最終成果物であるILやバイトコードを生成しないので、正確に言うとコンパイラー(compiler: 翻訳者)ではないんですが(パーサー(parser: 文法を説明するもの)というのが正しい)。

例えばこれはJavaの話なんですが、「JDK 8のプレビューがリリースされたけども、Eclipseのコンパイラーが8未対応だからまだ(最近まで)Java 8は使えない」なんていう不思議な話が聞こえてきます。要するに、(本来の、バイトコードを生成する)Javaコンパイラー的には問題ないコードを、Eclipseはエラーだと認識して警告を発していました。

今までのVisual Studioにも実はこういう問題にあたる可能性はあって、それがないのは単純にマイクロソフトが2重のコストをかけてちゃんとC#コンパイラーとVisual Studio上のC#パーサーが一致するように頑張っている(一致するまで公開されない)からです。

“もう1つのコンパイラー”(IDE上のパーサー)

ではその”もう1つのコンパイラー”がどういうことに使われているのか(つまり、IDEがC#の文法を理解しなければならない理由について)、いくつかの例を見てみましょう。

構文ハイライト

多くのIDEでは、プログラミング言語のキーワードやコメント、型名などにそれぞれ色を付けて、ソースコードを見やすくしています。こういのを、構文ハイライト(syntax highlighting)とか言ったりします。

Figure 1: Visual Studio上に表示したC#コード(色が付く)

ある程度は、正規表現みたいな単純な文字列検索でもできるんですが、C#の場合は特定の文脈でしかキーワード扱いされない単語も多いですし、ちゃんと色付けするためにはIDEがC#の文法を理解する必要があります。

リアルタイムなエラー検出

コンパイル式のプログラミング言語の場合、多くの人為的ミスはコンパイル時に発見されます。

もっというと、IDE上では、コンパイル時どころか、リアルタイムにエラーを発見してその個所を示します。

Figure 2: リアルタイムに検出したエラーが表示されている例(これはVisual Studio 2013にProductivity Power Toolsというプラグインを入れた状態)

コード補完

プログラミング言語では、文脈ごとに、そこに書いて正しく解釈できるコードが結構限られています。そして、限られているのなら自動的に埋める(補完する)こともできます。こういう、自動的に埋めれるものをIDEが埋めてしまう機能をコード補完(code completion)といいます。

例えば、クラス名などを途中まで入力するだけで残りを補完して出したり(IntelliSense)。

Figure 3: クラス名の補完(IntelliSense機能)

解決方法がはっきりしているエラーに対して、その解決方法を提示したり(スマート タグ)。

Figure 4: エラーが出ている箇所に表示されるスマート タグ

Figure 5: スマート タグによるコード自動生成結果

よく使う定型文を、短縮形のキーワードを使ってコード生成したり(コード スニペット)。

Figure 6: コード スニペットの例

Figure 7: コード スニペットによるコード自動生成結果

リファクタリング

取り急ぎ動くようになるまで書き殴ったソースコードは、往々にして、機械的な書き替えでより読みやすいコードに修正できたりします(機能はそのままで、読みやすいよう、今後の機能追加がしやすいように書き替えることをリファクタリング(refactoring)といいます)。当然、機械的にできることはIDEにやらせるべきです。

Figure 8: メソッド抽出(Visual Studioのリファクタリング機能の1つ)の例

Figure 9: メソッド抽出の結果

つまるところ

IDE上では、バックグラウンドで常にコンパイラーが動いていて、一字一字書き替えるたびに、その書いたソースコードがどういうものかという情報を更新し続けています。このコンパイラーには以下のような要件が求められます。

  • ソースコードのどこからどこまで(何行何列目)が何かという情報がとれる
  • 文脈に応じてソースコードを生成したり、書き替えたりできる
  • リアルタイム処理を必要とするので、パフォーマンスも求められる

コンパイラーを1つに

もちろん、2つの異なるコンパイラーを保守するのは容易ではありません。プログラミング言語への新機能の追加には2重の労力がかかります。余計な労力がかかるということは、新機能の追加にも慎重にならざるを得ません(開発リソースは有限です)。コンパイラーを1つにできるのならぜひとも1つにしたいです。

コンパイラーが2つになる理由は、(ILを生成する)通常のコンパイラーが最終成果物(要するにIL)以外のことに無頓着で、IDEが必要とする情報を返さないことにあります。

なら、最初から、IL生成という最終目標に加えてIDEが求める中間情報を取れて、ソースコードの自動書き換え機能も想定していて、リアルタイム処理にも耐えうるパフォーマンスが出るコンパイラーを作れば、コンパイラーは1つだけにできます。

これがRoslynというプロジェクトの目標です。当初考えられていた以上にこの目標は大変(既存の、2つにわかれているコンパイラーとの互換性維持も大変さの理由の1つですが)で、工期は長くなってしまいました(Roslynというコードネームのこのプロジェクトの発足が公開されたのは2011年)が、今年ようやく完成が見えてきました。

そして完成すれば、C#への新機能追加のコストが激減します。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。