R6RSのライブラリ その４

ライブラリというよりはコンパイラ自身の問題か。

現在自前コンパイラを一つのライブラリにしてコンパイルしようとしている。
コンパイラはGauche上で実装されているので、Gaucheが実行できるコンパイラとそれをR6RSのライブラリにしたコンパイラと2種類ある。
(別に管理するのは面倒なので、cond-expand等を用いてできる限り最小限の重複にしてる、つもり)
っで、ライブラリのコンパイラは一つのライブラリなのにサイズが100KBを超える。多分この辺で問題が発生してる(と思う)。

libraryのコンパイルの順序として、
参照名の解決(不完全実装)、import句の解決、export句の解決、bodyのコンパイルという順番で行っているのだが、
bodyをコンパイルするさ際に、イメージとしてbodyをbeginで包んでからコンパイルしている。
こうすることで1つコンパイル、実行、というのを繰り返さず、全体をコンパイルして実行という感じにできる。
っで、(多分)上記のサイズが問題になってくる。
メモリが足りてないような症状が出てる気がする。というのも中間表現をライブラリ毎にダンプした際に、コンパイラのダンプだけ途中で途切れているからだ。
(本当に途中。ダンプせずに実行するとベクターじゃなく#fだって起こられるのに、ダンプするとぷっつりと死ぬ)
これがWindows版Gaucheだからなのか、そもそもベクターであんまり巨大(といっても目視で16MBしか使ってないけど)なデータを使えない仕様なのかわからない。

解決案は多分いくつかあって、簡単なのでライブラリの分割かな。
ただ、ライブラリを分割するということは、内部にとどめておきたい機能を外部公開する必要がでてくるので、すごく嫌だ。
一つのファイルに複数ライブラリを記述して、参照解決の際の検索方針とかでJava風なライブラリ解決にすれば、実質使えないかもしれないが、ものすごく抵抗がある。
(将来的に直すということにして現状の解決ためということにすればいいのかもしないけど・・・)

さて、どうしたものか。