よく考えたら(define id expr)の形式で定義されるidは自前VMだとライブラリをプロパティとして持つので、
そこを参照すればいいことに気づいた。
(もともとそのためのものなので早く気づけよ)
とりあえず、importのforキーワードについてはガン無視することにした。
あまりに理解して無さすぎなのと、明確にマクロ展開時((meta 2)以降はそれ以前になるの？)とコンパイル時と分かれているわけではないので、
実装しても煩雑になる上にあまりメリットが享受できそうになかったから。(単なる言い訳)
いい加減ながらライブラリの実装がほぼ完了。あとはバージョンを残すのみ。
でも、バージョンなんてどう管理すんだ？ということで少し整理。
現在のライブラリの構造。
top-libraries - 単なるハッシュテーブル
library - name, imported, exported, tableを持つクラス(もしくは構造体)になる予定
(現在は単なるベクター)
構造として
top-libraries = (lib1 => (lib1 instance)
lib2 => (lib2 instance))
こうなってるので、このどこかにバージョンをねじ込む必要がある。
案１：
もう一枚かませる。こんな感じ。
top-libraries = (lib1 => (version1 => (lib1 v1 instance)
version2 => (lib1 v2 instance))
lib2 => (version1 => ... ))
案２：
キーにしてる名前にバージョンをくっつける。
top-libraries = (lib1version1 => (lib1 v1 instance)
lib1version2 => (lib1 v2 instance))
lib2version1 => ... )
案３：
そんなことよりカラオケ行こうぜ！
３は無いとして(当然)、２だと微妙にメモリ消費が少なくなる気がするけど、バージョンマッチで死ぬ気がする。
１は現状の構造をいじる必要があるので、少し大掛かりになりそう(そうでもないが)
あぁ、そもそも、キーを(name version)みたいにして、やればいいのか。
(rnrs (6))みたいな例だと(rnrs (6))ってそのままになるな。
(com hoge fuga)ってのだと、適当にバージョン振る必要があるから、まぁ１だろう、こうなる？(com hoge fuga (1))
ということは、バージョンが無いものに関してはバージョンを振って、あるものはそのままキーにすればいいのか。
っで、参照する際に名前とバージョンを解決すればOKと。
とりあえず、この方法で行ってみよう。
どうでもいい話題で、export-allなんてのを作れないかなとか考えていたのだが、
結構大変そうだなぁということに気づいた・・・
importしたシンボルはまぁいいとして、中で定義されてるのを引っ張り出すのが大変そう・・・
でも、rnrsとかの巨大ライブラリを書くときに、export句に全部書き出すのって大変じゃね？っていうだけの話。
