NETRuby

NETRuby（これは総称。実際のクラス名はNetRuby）は、RubyをC#で再記述する試みだ。

心境の変化

以前、次の公式を書いていた。 Java : JavaScript = Ruby : NETRuby 要するに、NETRubyは、Rubyに似ているが全くの別物である、と。
Javaには、JDKがある。JavaScriptにはそんなものは無く、ホスト環境のオブジェクトモデルがあるだけだ。
NETRubyは、.NET Frameworkを操作するためのRubyモドキ（＝Javaに対するJavaモドキのJavaScript）という位置付けだ。

ASRの理由

Win32には、ろくな簡易言語が無いと言うのがActiveScriptRubyの開発動機だ。 VBScriptもJScriptも有体に言えば機能不足だが、かと言って、いちいちC++やJavaでちょろっと書くのは馬鹿げている。コンパイラを通すわけだから、その分手間がかかるし、ちょこちょこ変えながら処理させていくというスタイルには合わない。そもそも「ちょろっ」とUIを書くのは面倒だ。
だが、インフラとしてIEが存在するわけだから、まともな言語のActiveScriptブリッジがあれば、それでOKじゃないか。C++やJavaを使う必要は無いわけだ。
ここで、僕はPerlもPythonも触ったことが無かったということが、ASRにつながっていく。同一スタートラインから、Perl、Python、Rubyを見れば、オブジェクトが操作のベースにあるという一点だけで、Rubyが勝利したわけだ（まあ、途中でHaskelとかも見たり（全然、この文脈とは関係ない言語だが、未知なものには興味があるし）、Forthのサンプル実装（があるし、軽いから拡張しやすそうだったし）に傾いたこともあるんだけど、日本語ドキュメントがある3大スクリプト言語の一つってのがやっぱり大きかったのかも）。

新たな環境の出現

そこに、.NETだ。で、同様な理由から、NETRubyにつながっていくわけだ。ここでは、実はコンパイルは問題では無い（矛盾してるように見えるかも知れないが、一番重要なのはリフレクションの操作だったりするから、「その言語を使って実現したいこと」が、Win32の場合とは異なってるのだ）。
その試みがここにあった。
が、やめた。というのは、この目的にはC#で十分だからだ。要するにC#はすごく気に入った。

わかっていること

なお、ハロウィン文書は熟読してるから、当然、CLRが撒き餌ってことは先刻承知だ。Monoの連中のことは知らんが、僕は、いわゆるMS的なバータリーで、目先の変ったアプローチが好きなんだよ。
だから、基本的にバータリーなのさ。っていうか、リアルワールドとは正反対のアプローチを取れるってのが楽しいのかも知れないな。

現在の方向

そもそも、NETRubyをRubyモドキにしようとしていた大きな理由がある。Enumerate

仕様が変りつづけているから、バージョンを作っても本家に追随できないだろう。
規模デカ過ぎ。
上のの詳細として、絶対に僕が使わない（学生の時だったら話は別だし、存在意義は非常に高いと考えているし、それがあるからいいとも言えるんだけど）機能が含まれている。

わけだから、クソマジメにポーティングしたくは無いと感じるのは当然だ。

愚公山を移す

おやおや、JRubyとか作ってるよ。つーか、やればできるじゃん？　あっちは、4人がかりみたいだけど、僕の生産性は少なく見積もっても5人分だから（当社比。言うだけならタダだよな）、どうにかなるんじゃないか？　――　もちろん、ここはバカな考えだった。リアルワールドでの生産性を真夜中の油に当てはめちゃいかんよね。
なお、JRubyはソースが分割され過ぎているし、コーディングスタイルがJava過ぎて読む気になれないから、ほとんどというかまったく参考にしてないわけなんだが。
もちろん、JRubyが存在するからといって、最初に挙げた理由は消えていない。しかし、考えて見たら、もともとのNETRubyがRubyモドキだと宣言しているわけなんだから、1.6モドキということで折り合いが付いてたり。
あと、非常に大きな理由として、Monoの連中がJayのC#対応修正を完了させていたってのがある。
個人的に本家の仕様変更が気になるのは、何よりパーサのポートが重荷だったからだ（細かなクラスの動作の差は大して気にしてない。そもそも、StringをUnicodeベースにするって決定しているわけだから、100%互換になるはずが無い）。
ここが、parse.cからのポートをするのか、parse.yからのポートで済むのかってのは、作業量的には非常に違うからだ。
っていうわけで、NETRubyは、Java:JavaScriptから、Ruby:JRubyの線で行くことにしたのであった。

NETRubyの理由

T.B.D

実装

オブジェクト

これだ。まだ、四則演算くらいしかできないけど。
JayのC#ポートが無くてもメークできるように、生成後のC#ソースも同梱してある。
ソースの解説

ファイル名	オリジナル	備考
NetRuby.cs	eval.c＋ruby.cってとこ	メイン。巨大クラス
nrb.cs	main.c	相当
Kernel.cs	sprintf.c＋object.c	sprintfマンセー（いい加減だけど）
Object.cs	object.c + ruby.h	うーん……
Class.cs	class.c	ここ好き
Node.cs	eval.c	相当充実してきた
Scanner.cs	lex.c + parse.y	そのまんま
Parser.cs	parse.c	Monoの連中のエフォートに感謝
parse.y	parse.y	そのまんま
Numeric.cs	numeric.c	仮想関数の恩恵
Bignum.cs	bignum.c	ムズイ……
excep.cs	error.c	迷いがある。.NET Frameworkのクラスを使うほうが正しいのでは無いか?
Const.cs	object.cなど	シングルトンで即値代わり
Symbol.cs	ruby.h object.cなど	相当無理がある
frmobj.cs	win32ole.c	これが無きゃね。
Array.cs	array.c	ArrayListラッパ
String.cs	string.c	Stringラッパ?
Proc.cs	eval.c	Proc
Thread.cs	eval.c	Thread関連
Time.cs	time.c	.NET Frameworkはtime_tじゃないから面倒だ
Enum.cs	enum.c	Enumerable
Regexp.cs	re.c	Regexラッパ
Hash.cs	hash.c	Hashtableラッパ
Loader.cs	eval.c	requireとかの処理
io.cs	io.c	3/10開始
Makefile	Makefile.subとか	nmake 7

やっぱり、小迫さんはすごい。としみじみ思う。
.NET Framework SDKがあれば、メークできる。英語版のリリースでも、日本語Windows2000SP2+IE5.5SP2UPにインストールし、動作している。

サンプル

一応、VB.NETとC#の組み込みサンプルも同梱してある。Netruby.dllに対してLIBPATH通すか、Netruby.dllと同一ディレクトリでコンパイル可能。
英語ページにも書いたが、現時点で将来までAPI互換性を保証できるのは、NetRubyクラス、NetRubyクラスの無引数コンストラクタ、Init()メソッド、EvalString()メソッド、Funcall()メソッドだけ。
また、現時点のNetRubyのインスタンスはスレッドセーフでは無い。

以前の試み

Last modified: Sun Mar 10 22:36:13 LMT 2002