ピックアップRoslyn 4/22: Expression Trees

先週末はあんまり拾うところがなくて定期ポストをサボっていたら、月曜日にまとめて大量の C# Design Meeting Notes が公開されていたり。ということで、今週は週末にまとめてじゃなくてちょっとずつ。

とりあえず今日は1件だけ。

C# Design Meeting Notes for Apr 14, 2015 #2134

https://github.com/dotnet/roslyn/issues/2134

Bart De Smet(Bing チームの方。ググったら、C# Unleashed の著者で、今は Cortana がらみの仕事してるっぽい雰囲気)が来て、式ツリーの利用方法についてディスカッションをしたそうです。

要するに、

• 式ツリーにはいろいろ足りない
  • C# 3.0で導入されて、C# 4.0で少し追加はあったけども、それ以降止まっている
  • 現状の C# の言語機能に対して、そもそも対応するクラスがないものがある
  • ラムダ式からの Expression 型生成はさらに制限がきつい
• Bing 内の分散コンピューティングで、ノードをまたいだ処理をするために式ツリーを使っている
  • (独自方式で)シリアライズして、他のノードに送る
  • 受け取った側でデシリアライズして、Compile してから実行する
  • 足りない機能を埋めてほしい
• Bing チームは非常に重要なユーザーだけども、典型的なユーザーとは言い難い(結構特殊な用途)
  • Bing チームの要望は受け入れるつもりだけども、問題は他の機能との優先度付け
  • 広く意見を求めたい

という話。

以下、今の式ツリーに何が足りてないか / 何が埋まれば Bing チームが喜ぶかというものの説明。

Expression Tree API の問題

まず、式ツリー API (System.Linq.Expression 名前空間以下の各種クラス/メソッド)自体の問題。

Dynamic

.NET 4 での式ツリーの拡充は C# 4.0 の dynamic を実装するのに大いに役立ったものの、皮肉なことに、その C# 4.0 の dynamic 構文自体は式ツリー化できない。

Bing チームとしては、ノード間を祖結合にするために、緩い型付けで式ツリーをシリアライズしたいことがあって、ぜひとも dynamic に対応してほしそう。あるいは、何らかの「lightweight dynamic」(現状の dynamic ほど大掛かりな仕組みじゃなくて、もっと軽量な緩い型付けの仕組みが)があれば、それを式ツリーでも対応してほしい。

Await

await 演算子は、式ツリーを得るだけならおそらく簡単なものの、それを Compile しようと思うと結構な複雑さ(現状の C#/VB コンパイラーがやってるのと同程度には)になるはず。

言うまでもなく、Bing みたいな分散シナリオでは、await を大量に使う。

Null conditional operators and string interpolation

この辺りは式ツリー ノードに加えるべきだと思う。たぶん、Compile 前にちょっとしたノード置き換え(reduce)を行うだけでよくて、Compile メソッドや、(LINQ to Entities とかの)式ツリーを使う側は、直接この新しいノードに対応しないでも大丈夫にできそう。(こういう置き換え可能なノードを reducible node っていう)

Higher level statements

式ツリーは制御構文も書けるものの、低レベルなものしかない。要するに、ｌoop はあっても(C# でいうと while 程度)、for や foreach ノードはない。この辺りも、reducible (loop への置き換えで対応できる)なはず。

言語機能的な問題

.NET 4 で、式ツリーのノードは種類を増やしたけども、ラムダ式から式ツリー化できる構文は増やさなかった。

当時、ラムダ式での対応を増やさなかった理由の1つは、既存の LINQ プロバイダー(式ツリーを解釈して動的にクエリを発行する、LINQ to Entities とかみたいなライブラリ)が対応しかねるという問題があったから。

これに対して、Roslyn がある今なら、アナライザーを書くことで、「このライブラリではこの式ツリー ノードだけを受け付けます」みたいな診断ができるようになったので、この問題をクリアできるはず。C#/VB の文法上は任意のラムダ式を式ツリー化できるようにして、各ライブラリがその手のアナライザーを付属させて配布すればいい。

制限を緩めるだけなので、新しい文法は必要としないし、割かし素直にできるはず。

結論

式ツリーの拡充、ラムダ式からの式ツリー構築の制限緩和は、「やるべきではない」といえる理由がもうない。

問題は単純に手間で、結構大きな請負仕事になりそう。他の新文法がらみの作業との兼ね合いを考えた上でも、この作業を正当化できるかどうかは確証を得てない。Bing チームは重要なユーザーの1人だけども、典型的なユーザーとは言えない。

言語デザイン チームとしては、こういう要望をかなえることは確約したい。あくまで優先度付けの問題として、広く意見を求めたい。