Roslyn CTP – October 2011 を触ってみた

先日インストールしたRoslyn、ちらほら見始めています。公式サンプル、ドキュメント、Walk-Throughや、フォーラム、twitter（ハッシュタグ #RoslynCTP）等々。

Codename “Roslyn”とは

Roslynは、C#とVBのコンパイラーをManagedコードで書き直して、コンパイラー内部の中間的な情報に誰でもアクセスできるようにします。

今までは、文字列のC#ソース コードを与えて、バイナリの.NET Assemblyを出力する一枚板（monolithicな）ブラック ボックスでした。一方、Roslynでは構文パーサー、意味解析エンジン、ILコード生成部、スクリプト エンジンなどを公開していて、ソース コードの静的解析やリファクタリング ツールなどを作りやすくなります。

Roslynの最終目標

Roslynの説明でよく使われるのが以下の絵。

「BUILD 2011 TOOL-816T: Future directions for C# and Visual Basic」より

つまり、目標は以下のようなものです:

• 独自のコード解析ツールや、リファクタリング ツールを作りやすくする。
• REPL（いわゆる対話的実行環境で、1行1行実行しながらコードを書く）利用。
• C#/VBへのDSL（domain specific language: 特定領域向けの独自言語）の組み込み。

そして、提供されるAPIには、大まかに、以下のようなものがあります。

「Whitepaper: Roslyn Project Overview」より

それぞれの意味は以下の通り:

• Compiler: 前述のような、コンパイラーの内部で使う、構文木や意味解析結果を参照するAPI。
  • C#とVBそれぞれで専用のAPIを提供
• Scripting: C#やVBをスクリプト環境（アプリへの組み込みを想定）用のAPI。
• Workspace: ソリューション（複数のプロジェクトを持つ場合も含めて）全体にわたって情報を得るためにAPI。
• Service: Visual Studio IDEの機能（IntelliSenseやリファクタリング）と連携するためのAPI。

October 2011 CTPの現状

現状のRoslynは、Visual Studioが前提/最優先な感じですね。

まだ最初のCTPなので、優先事項がはっきり表れています。

Workspace/Service API

まず、Workspace APIの、ソリューションの下にプロジェクトがあって…というような構造が、Visual Studioのそれそのもの（そんなに変なことはしていないので、「Visual Studioに依存」というほどのものではないですが）。

Service APIに至っては、そもそもVisual Studioを拡張するためのAPIという感じです。

そして、October 2011 CTPで、サンプルの比率が一番多いのはService APIになります。明らかにここが優先事項になっている感じ。

Visual Studio拡張の例（公式サンプルの説明）はこちらのブログ（MSDN, Visual Studio Blog）などに:

• Roslyn Syntax Visualizers

Scripting API

次点でScripting API。サンプルやWalk-Throughもそこそこあります。ただし、現状はC#のみ。

一応APIはそろっているので、自分で作ったプログラムにC#スクリプトを組み込むことは可能。

Host Object Model（スクリプトのトップ レベルがどういうオブジェクトになっているかを指定。スクリプトで使ってもらいたいメソッドなんかの文脈を与えられる）を指定してC#スクリプトを実行できます。

一方、（プログラムを作ることなくC#スクリプトを実行できる）Roslynに含まれている実行環境としては以下の2つです。

• rcsi.exe:
  • （対話的でなく）スクリプトを一気に実行する。
  • \Program Files (x86)\Microsoft Codename Roslyn CTP\Binaries にあります。
• C# Interactiveウィンドウ:
  • Visual Studio内のウィンドウでC# REPL。
  • IntelliSenseやコードの自動整形など、通常のC#エディターでできることはこちらでも働きます。

つまり、（Visual Studioの外で動く）単体のC#スクリプトREPL環境はまだありません。

Compiler API

とりあえず、C#/VBの機能のうち、主要なものだけは実装できたというレベルです。（参考: 未実装項目一覧）

まして、組み込みDSL的な方面の機能は全然。通常のC#/VB（のサブセット）をパース/意味解析できるだけです。

また、拡張性などを考えすぎることでパフォーマンスを落としたくないようです（C#/VBは、Visual Studioでリアルタイムに構文チェックして、ハイライトやエラーの指摘をする前提なので、コンパイラーのパフォーマンスはVisual Studioの使い勝手に直結するため）。

DLRとRoslyn

Roslynと似たようなものに、DLR（Dynamic Language Runtime）があります。主目的は、以下のように差があるんですが、結局、近い部分もあるはずで。

• DLR:
  
  • 動的言語を.NET上で動かすためのライブラリ。
    
  • Roslynでいうと、Scripting APIの部分が近い。
    
• Roslyn:
  
  • 上記の通り、一番力が入っているのは、いかにしてVisual Studioとコンパイラーを連携させるかという部分。
    

構文木

DLRとRoslynの一番の差は、DLRがSystem.Linq.Expressions名前空間以下の式ツリーを使っているのに対して、Roslynは使っていない（直接ILを生成）ところですかね。

式ツリーは、どんな言語でも使いそうな汎用的で、比較的低レベルな構文にしか対応していません。たとえば、yieldステートメントに対応する式ツリーを持っていないのは当然として、ループも1種類（while(true) { }に相当。適宜breakする前提の永久ループ）しか持っていません。

DLRでは、例えば、IronPythonなら、Python専用の構文木から、一度、式ツリーに変換して、それを実行する仕組みをとります。

一方、Roslynでは、C#/VB専用の構文木から、直接IL生成します。これは、前述の通り、パフォーマンスを得るためと思われます。

DLR利用プログラムからC#スクリプトを利用

要望は出ていて、それに対する回答としては、「考えてはいる。今はまだ。」という感じのようです。

ちなみに、DLRからC#スクリプトを利用というのは、app.configへの設定と、以下のようなコードでC#スクリプトを実行できるようにしたいというものです。

var engine = scriptRuntime.GetEngineByFileExtension(“.csx”);

メタプログラミング

Roslynのスコープに入っているのは、組み込みDSL（C#/VBの内部に、独自の拡張構文を組み込む）です。

それに、現時点のOctober 2011 CTPでは、その手の機能は全くなさそうです。

独自のパーサー定義はスコープ外

つまり、MGrammarでやっていた様なことは想定外ですって。

MGrammar ＝ SQL Serverチームのものだった

まあ、SQL Server Modelingという製品の一部として世に出たものですからねぇ…

SQL Server Modeling自体はお蔵入り、M言語は残すらしいけども、M言語の行く末はVisual Studioチームの知る由ではない模様。

世に出す場所を間違えたか…

DSLといっても、大部分は既存の言語の文法を使いたい

特殊な、独自の文法を使うに値する部分はそう多くないといわれています。DSLに条件分岐とかの制御構文を含めたいことも多々あるわけですが、その場合、C#使いならC#のifを、VB使いならVBのIfを使いたいわけです。

なので、独自パーサーのサポートまでスコープに入れるつもりがないんでしょうねぇ。

UnknownAccessor

現状、言語拡張できるポイントがないと思っていたんですが、1個、拡張に使えそうな点が。

案の定というか、まず真っ先に思いつくこととして、依存関係プロパティの自動実装のためにRoslynを使う人がいるわけですが:

• In bed with RoslynFuture directions for C# and Visual BasicFuture directions for C# and Visual BasicFuture directions for C# and Visual BasicFuture directions for C# and Visual Basic

で、サンプルのコードを見ていると、以下のようなものが。

[dependency] public int Widgetude
{
change { /* on-change logic here */ }
}

changeアクセサー！

どうも、これ、構文のパースまではできるみたいです。意味解析の時点でエラーになりますが、構文解析の時点のSyntaxTreeを書き換えることでメタプログラミング可能。ちなみに、構文木的には、ノードの種類がSyntaxKind.UnknownAccessorDeclarationというのになります。