ささだです。
　暑くて眠れないので投稿します。


２００４年度未踏ソフトウェア創造事業　「未踏ユース」　公募結果
http://www.ipa.go.jp/jinzai/esp/2004youth/koubokekka.html
が公開されていました。

「9. 淺川　浩紀さん Ruby.NET コンパイラの開発 管理会社：三菱マテリアル(株) 」

　というプロジェクトも採択されたそうです。いやーん、ガチ対決？

　どなたか、どんなプロジェクトかご存知のかたいらっしゃいませんか？
いずれ、ミーティングとかで会うことになるとは思うんですが
（管理組織いっしょだし）





　この方法の是非なんですが、前IRCで首藤さんとちょっとお話した
ことがありました。

　仮定として、「Ruby .NETコンパイラ」とは、「RubyAST を .Net CIL(*1)
に落とすもの」であると考えます。

（JRuby のようなものかもしれませんが、私はこっちじゃないかなぁ、
と思うんですが、どうでしょう。まさか、パーサレベルからやるとは
思えないんだけど）

CIL: Common Intermediate Language
http://download.microsoft.com/download/6/8/8/68863d89-d35d-4bc5-8a1c-7e0a02e1881e/Partition_III_CIL.zip


　この CIL にあたるものが、YARVの命令語にあたるものだと思います。



・YARVの利点、.NET Compilerの欠点：

1. IL（中間言語）の仕様がyarvのはRuby的に有利

　yarv は rubyべったりに作りますので、その中間語はRubyの実行
に適したものが作られます。Rubyを CIL に載せるためには、CIL の
モデルと Ruby の実行モデルとの齟齬がある（だろう）から、その
隙間を埋めるコードが必須となる。たとえばクロージャを実現したい
と思ったとき、それをオブジェクトスペースですべてを管理するよう
になると、オーバヘッドがでかいような気がします。

　となると、CILのメソッド呼び出し機構使わないのかなぁ？　スタック
を取れるだけでかく取って、自分でスタックマネージメントするような
形に・・・。駄目か、ローカル変数への変数インデックスでのアクセス
はサポートしてないような気がした。

　また、YARVでは、それを実行するための最適化で細かいことを Cで色
々書けます、というか、書きます。


2. 既存のライブラリとの互換性を考慮可能

　考慮可能っていうだけで、互換性が保たれることが保証できるわけじゃ
ないんですが・・・。

　できるだけ互換性があるように作るつもりではあります。

　ここでのライブラリはC拡張ライブラリを指しています。


・YARVの欠点、.NET Compilerの欠点：

3. .NET CLR(Common Language Runtime)の最適化器の品質が段違いにイイ

- code optimizer
- JITコンパイラ

　などの品質はどんなに頑張っても勝てません。多分（時間、人材的に）。

orz


4. 豊富なライブラリへのアクセスが約束される

　どちらかというと副次的なメリットですが、利用者的には超でかい
ですよね。



・不明

- C の今までのライブラリとの互換性がとれるのかな？
- GC とかどうなるんだろう
- 例外機構はすんなり乗るんだろうか
- eval とか動くのかなぁ（環境管理的に）
- 何が彼をこれに向けさせたんだろう



・まとめ

　1 と 3 のトレードオフですよねぇ。多分。首藤さんには 3
によって .NET の勝ち〜って一刀両断されちゃったんだけど、
Groovy の処理速度とか見ると、やっぱりそんな簡単じゃない
んじゃないかと思います。（と思わせて orz）

（議論で抜けている点などあれば、ご指摘ください）



--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml