デファクトスタンダードでフリーなバーチャルマシンの必要性

まぁ、私が必要としているというだけのことですが(笑)…

バーチャルマシンというと、Java VMが思い浮かびますが、あれはSUNからOracleに権利が移っているようで、どうも…という…

で、オープンソース界隈ではエイプリールフールねただったPerl6のParrotがどうにかなるのかなとおもったら、それほど話を聞かないし…

ここで大切なのは、JITコンパイラが各種CPUに対して、すでに存在するというのが非常に重要です。

(そういうのが出てくれば、Emacsのバイトコードもそれになるでしょうから高速化されますね…)

で、LLVMがそういうやつなのかなという感じがしていますが、どうなんでしょう…

とは言え、Lisp to C translatorで、型推論とかするコードはターゲットをLLVMのビットコードとしても、意味を持つのでまぁ、時代の流れに合わせます…

私はノイマン型コンピュータをバーチャルマシンとしてソフトウェア的に抽象化することに賛成です。

LispからCへのトランスレート

Lisp, Ruby, Pythonなどのダイナミックな型の言語をCへトランスレートするときに実行速度を気にするなら、いかに型推論をうまくやるかがキモだと思われます。

で、私は型推論に関してはまったくの初心者です(笑)

数十年前にMLかHaskellのチュートリアルをネットで読んで、これはいいものだなと思いました。

当時から思っていたことは、

「人間がコーディング中に考えて、型を特定してオプティマイズできるということは、そういう判断基準がこの世に存在するということ(あとはそれをコードにすればいいだけ)」

です。(そういう判断をするコードは計算量のオーダーが…という意見には、ゲリラ的に解決します!と答えます…)

で、そういうLisp to C translatorを書けたら私は成仏するんだと思います(笑)

KISSのILOS実装は決定打までやるか?

ISLispのオブジェクトシステムILOSのオブジェクトのスロットをC言語のレベルでの構造体のメンバーにじかにするとO(C)レベルでのアクセスが可能ですが、ILOSは制限付き多重継承を許しているので、その前のスロット位置の計算にまたでかいO(C)レベルの計算量(ハッシュテーブル? シンボルに書き込む?)がたぶん必要になります。

………スロットはplistでいいだろ……(どうしようかな…)

———————————-
午後に気が付いたんですが、C言語へのトランスレートを視野にいれると、トランスレート時にスロットの位置は確定しますね… ILOSはCommon LispのCLOSとちがってクラスの動的な再定義はなしです。

多重継承を許しているC++がコンパイル時にそういうことやってるんだから当然ですね…勘が鈍っている…

———————————-
翌日ですけど、そういえば、C++のメソッドにはvtableがあってとか少しずつふわっと思い出してきました。