まぁ、私が必要としているというだけのことですが(笑)…
バーチャルマシンというと、Java VMが思い浮かびますが、あれはSUNからOracleに権利が移っているようで、どうも…という…
で、オープンソース界隈ではエイプリールフールねただったPerl6のParrotがどうにかなるのかなとおもったら、それほど話を聞かないし…
ここで大切なのは、JITコンパイラが各種CPUに対して、すでに存在するというのが非常に重要です。
(そういうのが出てくれば、Emacsのバイトコードもそれになるでしょうから高速化されますね…)
で、LLVMがそういうやつなのかなという感じがしていますが、どうなんでしょう…
とは言え、Lisp to C translatorで、型推論とかするコードはターゲットをLLVMのビットコードとしても、意味を持つのでまぁ、時代の流れに合わせます…
私はノイマン型コンピュータをバーチャルマシンとしてソフトウェア的に抽象化することに賛成です。
Lisp, Ruby, Pythonなどのダイナミックな型の言語をCへトランスレートするときに実行速度を気にするなら、いかに型推論をうまくやるかがキモだと思われます。
で、私は型推論に関してはまったくの初心者です(笑)
数十年前にMLかHaskellのチュートリアルをネットで読んで、これはいいものだなと思いました。
当時から思っていたことは、
「人間がコーディング中に考えて、型を特定してオプティマイズできるということは、そういう判断基準がこの世に存在するということ(あとはそれをコードにすればいいだけ)」
です。(そういう判断をするコードは計算量のオーダーが…という意見には、ゲリラ的に解決します！と答えます…)
で、そういうLisp to C translatorを書けたら私は成仏するんだと思います(笑)
妄想のたぐいですけど、仲の良いフィリピーナといいかんじにDNAがまざった子をもうけて、その子にLisp処理系を書かせる英才教育(星一徹)をしてみたいな…
— 峯島雄治 Minejima Yuji (@yuji_minejima) October 12, 2019
ISLispのオブジェクトシステムILOSのオブジェクトのスロットをC言語のレベルでの構造体のメンバーにじかにするとO(C)レベルでのアクセスが可能ですが、ILOSは制限付き多重継承を許しているので、その前のスロット位置の計算にまたでかいO(C)レベルの計算量(ハッシュテーブル？ シンボルに書き込む？)がたぶん必要になります。
………スロットはplistでいいだろ……（どうしようかな…）
———————————-
午後に気が付いたんですが、C言語へのトランスレートを視野にいれると、トランスレート時にスロットの位置は確定しますね… ILOSはCommon LispのCLOSとちがってクラスの動的な再定義はなしです。
多重継承を許しているC++がコンパイル時にそういうことやってるんだから当然ですね…勘が鈍っている…
———————————-
翌日ですけど、そういえば、C++のメソッドにはvtableがあってとか少しずつふわっと思い出してきました。
