生成コードの組み込み

今のところ、moshには./configureの結果で内蔵ライブラリを増減させるためのインターフェースは無い(gaucheを必要とする--enable-developerは例外)。
多分、今後Windowsだけに現れる手続きとかtranscoderの出現が予測されるので、何らかの手段が必要になる。

Windowsだけ独自のfree-varsを準備する?

そのような方式はおそらく直ぐに破綻する。Windows/非Windowsの差ならまだしも、今後CPU固有の手続きであるとか他の物を入れようと考えるとその組み合わせは無限に増殖することになりスケーラビリティに問題がある。

fallback方式

Windowsでしか使えない物や、他の語彙に関して、対応していない場合は単に失敗するコードに誘導し、free-varsは常に"全部入り"にするという手段が考えられる。
これがどの程度妥当なのかは何とも言えない。一種のデザインチョイス。

skymosh方式

skymoshではこの目的のためにsymbol-valueを使っている。つまり手続きは毎回の実行時に新規に登録されることになる。

この方式では、symbol-valueを使って(R6RS側に)定義を取り出すstub libraryが必要になる。

生成コードの組み込み

skymoshの方式はエレガントとは言い難いので、--enable-developerしなくても、内蔵の定義を差し替える仕組みが必要になる。
ここでminimoshが必要になる。つまり、必要最低限の内蔵定義のみをもつmoshを先にビルドし、そのmoshを使って各種C++コードやschemeライブラリを生成し、シリアライズして組み込むという流れになる。
インタプリタではたとえばminiperlやminirubyを一旦作ってビルドするのと同じ流れと言える。
現状ベースで考えると、今まさにビルドされているmoshがminimoshに相当する*1ことになる。
少なくともskymoshは対応すべきライブラリ手続きの数が非常に多いので、こちらに移行する準備を進めている。moshの本流がこの方式になるかどうかは、Windowsやその他のOS固有の機能の数によりけりということになると思われる。たとえばtranscoderを入れる程度であれば、fallback方式でも特に問題ないように思える*2。ちなみに、現在のfallbackは%fork等のシェル周りがWindowsで常に失敗する程度。

*1:miniというprefixは別に小さくなることを意図しない。たとえばminiperlはXSのロードができないだけの差しかないほぼフルセットのperlになる。

*2:fallbackしなければならないケースが多い。mstranscoderをエミュレーションで提供するのはあまり望ましくないように思える。