++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

研究レベルのプログラミング言語等

leave a comment »

MS Research とか DevLabs とかでやってる実験的プロジェクトの中で、言語がらみのものをピックアップしてみる。

プログラミング言語の進化の方向性は「命令的から宣言的に、how から what に、intentional に意図をそのまま記述できるように)」って言われて久しく、C# 2.0 とか 3.0 でかなり intentional な感じになりました。さらにその先、「C# の今後」というと、「dynamic と concurrency」(動的実行・動的コード生成と同時実行制御・非同期制御)だと言われています。

研究言語を眺めてみると、プログラミング言語やフレームワークのここ数年の進化や今後の方向性が見て取れるんじゃないかと思います。

とりあえず有名どころから。C# 3.0 (LINQ 関連)の元になった言語なんで知ってる人も多い

C# 1.0 をベースに、データアクセス関連の文法(LINQ の元になった)と、同時実行のための文法(不採用。同時実行関連は今現在に至ってもなお色々研究途上)を追加したもの。

C# 3.0 が出てからは Cω がらみはもう継続されてないっぽい。データアクセス関連は完成、同時実行関連は別のプロジェクトに移行ってことかと。

結構色々やってた。

  • Streams
    • ぶっちゃけ、C# 2.0 のイテレーター
    • int* (IEnumerable<int> に相当)って書き方こそ採用されなかったけど、yield はまんま採用された
  • 匿名型
    • 文法的に修正されてるけど、コンセプトは C# 3.0 で採用
    • x = new { i = 42, new Button() } みたいに、名前なしのメンバーが持てた
      • x[1] で Button の方にアクセス可能
    • C# 3.0 でいうところの list.Select(x => x.Method()) みたいなのが、 list.{ it.Method() } みたいに書けた
  • Choice 型
    • C でいうところの union みたいなの?
    • C# には不採用
  • Content クラス
    • XSD のスキーマ的なものを C# 風の文法で書く手段を提供
    • C# には不採用
      • スキーマ定義系のものは、C# みたいな汎用プログラミングに文法追加はしない方向性みたい
      • むしろ、Entity Framework とか SQL Server Modeling みたいに、モデル定義が先にあって、そこから C# コードの自動生成みたいな方向が主流
  • XML リテラル& XPath 風文法
    • VB9 に採用されたアレ。C# には不採用
  • SQL 風の式
    • クエリ式の原型
    • この当時はクエリの解釈をコンパイラが頑張ってたのかな
      • C# 3.0 で採用されたのは、クエリ式を通常のメソッド呼び出しに変換して、ライブラリで自由に実装できる方式
  • 同時実行
    • あんまりわかりやすい文法でもなかったし、結局不採用
    • ぱっと見、アクターモデルの並列処理かな?
      • Task Parallel とか Parallel LINQ みたいなのじゃなくて、スレッド間でのメッセージングの仕組みを提供
      • Erlang とか Go の採用してるやつ
      • 後々、Axum (後述)につながっていく?

F#

F# ももともとは MS Research 生まれ。まさか Visual Studio の正式ラインナップに含まれようとは・・・

Cω の例を見てても、Research 製のものが全くそのままの形で製品版になることはめったにないんですけども、F# は例外的にそのまま製品に。

DLR

ライブラリですけども、C# 4.0 で追加される dynamic を語るうえで外せないんで Dynamic Language Runtime の話も。

  • 元々は IronPython から始まる
    • 「.NET は LL を実装するには向いてないってことを実証してやるぜ」みたいなノリで Python を .NET で実装したら、意外と行けたというか、むしろ性能よかったみたいな
    • そのまま、IronPyhon とかいう名前がついて、本格的に Python の .NET 実装をやっていくことに
  • IronPython のうち、LL 実装で共通利用できそうな部分をライブラリ化 → DLR 誕生
    • IronRuby ができたり、JavaScript の DLR 実装ができたり
  • .NET Framework 4 で正式採用
    • 元々 DLR の AST だったものが System.Linq.Expressions に統合される
    • その他、動的なメンバーアクセス用の機能も System.Dynamic とか System.Runtime.CompilerService 辺りに統合
  • そして、C# 4.0 でも dynamic キーワードで DLR とかとの連携がしやすく

Spec#

Cω に続いて古株の Spec#。C# に契約プログラミングの機能を足したもの。

契約プログラミングがらみは MS も相当に頭悩ましてるみたいですねぇ。なかなか製品に本採用されず、かといって研究レベルではずっと何かしら続けられてて。

契約って、仕様でもあり、静的に解析するものでもあり、動的なテストで確認したくもあり。そのあたりのツール類(ドキュメント生成とか静的解析ツールとかテストツールとか)との兼ね合いもあるんですかねぇ。

Sing#

Spec# をさらに拡張したもの。Singularity(Windows の過去のしがらみ捨てて OS 作ってみようぜ的な研究プロジェクト)の実装に使われてるとか。

Spec# にメッセージ パッシング用のチャネルの仕組みを追加したもの。以下の論文が詳しそう。

この辺りは C# に取り込まれるよりは、DSL 化していきそうな気もする。

Axum

同時実行用の DSL。これもベースは C# 風。C# と一緒に使うのを想定してるっぽい。

いわゆるアクターモデルを採用:

  • 要するに Erlang とか Go で採用してるようなタイプの同時実行制御
  • アクターモデルでいうところのアクターは Axum だと agent って言うみたい
    • 互いに状態を共有しない処理主体
  • エージェント間の情報のやりとりはメッセージ パッシングのみで行う
    • adder::Num1 <– 10 みたいな感じで、adder エージェントの Num1 に 10 っていうメッセージを送る
    • receive(adder::Sum) みたいな感じで、adder エージェントから Sum メッセージが来るのを待つ

Reactive Extensions

非同期実行系の文法は今後どうなるかなぁ・・・。Cω、Sing#、Axum と、それぞれ全然違うメッセージパッシングの仕組み持ってますけども。

あと、言語じゃないですが、Reactive Extensions とかいうフレームワークもあったり。

  • IObserver/IObservable ベースのイベント処理メカニズム
  • IEnumerable(LINQ to object)と同じようなノリで、LINQ 使って処理を書ける
    • IEnumerable が pull 型(データソースから要素を取ってくる)なのに対して、IObservable は push 型(観測者に対して随時データを渡す)

Axum みたいなやつはあくまで「C# と併用する DSL」って路線になりそうな気もします。現行の .NET Framework の延長でいくなら、この Reactive Extensions が非同期実行の本命かも。

Vedea

Vedea はプロジェクト名。Microsoft Visualization Language だそうで。要するに、グラフとかのプロット機能を持ったスクリプト言語(DLR で実装)的なものみたい。

で、プロット機能的なものにだけじゃなくて、データバインディングの機能を持ってるとか。

現状の C# だと INotifyPropertyChanged を実装して、Binding クラスを通して・・・とかものすごく面倒な部分を、textBox.Text :=: slider.Value だけで書けたり、というもの。

実体がまだ出てきてないんで何とも言えない状態。Area := Width * Height って書くだけで、以下のようなプロパティを生成するしくみがあるといいんですけどね。(あるいは、同様のことを実現する依存関係プロパティかを。)

public double Area
{
    get { return Width * Height; }
}

public double Width
{
    get { return _width; }
    set
    {
        _width = value;
        OnPropertyChanged("Width", "Area");
    }
}
double _width;

public double Height
{
    get { return _height; }
    set
    {
        _height = value;
        OnPropertyChanged("Height", "Area");
    }
}
double _height;

あるいは、Reactive Extensions 的な push 型の仕組みで値の変化を伝搬させるか?

おまけ

Mono が C# に独自拡張入れたらしい

  • 文字列補完
    • String.Format に対する構文糖衣
    • シングルクオート使う
      • ‘Hello {name}’ みたいな
  • タプルに対する構文糖衣
    • (a, b) = Tuple.Create(1, 2) みたいな感じでタプルの値を多値代入できる

どっちも MS 謹製 C# には採用されそうにないなぁ・・・。

タプルに関しては、多値代入よりも、Tuple.Create の部分に対して何か構文糖衣が欲しいですねぇ。@(1, 2) で Tuple.Create<int, int>(1, 2) と同じ扱いになるとか、そういう文法。

まとめ

  • データアクセス関連は C# 2.0 のイテレーターや C# 3.0 の LINQ でだいぶ解決
  • 動的実行関連は C# 4.0 / .NET 4 で大幅強化
  • 同時実行も、一部 .NET 4 で強化
    • Task Parallel
    • Parallel LINQ
  • 直近の課題は:
    • アクターモデル・メッセージパッシングによる同時実行・非同期処理
    • 値の変化の伝搬(データバインディング)
    • 契約プログラミング

Written by ufcpp

2010年2月2日 @ 17:11

カテゴリー: .NET

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中

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