"アプリケーションのビルド"をSDKとして抽象化できるのか問題
追記: Racket 7は--embed-dllsで完全にstandaloneな.exeを生成できるようになった https://blog.racket-lang.org/2018/07/racket-v7-0.html
実は意外に多くのScheme処理系が単体アプリケーションのビルドを機能としてサポートしている。
Gaucheは最新リリースの0.9.6でbuild-standaloneユーティリティ( http://practical-scheme.net/gauche/man/gauche-refe/Building-standalone-executables.html#Building-standalone-executables )を提供し、スクリプトとライブラリを文字列の形で取り込んだexecutableを作ることができる。ツールは(まだ実験的な)precomp( https://github.com/shirok/Gauche/blob/master/doc/HOWTO-precompile.txt )を活用しない。build-standaloneはSchemeソースコードをC文字列に変換し、簡単なmainスタブとともにコンパイルすることでアプリケーションをビルドする。コンパイラはgauche-config --ccのものがそのまま使用される。
ChezSchemeはmake-boot-file手続きでbootファイルを作り、それとバンドルされているstatic library形式の処理系を組み合わせて単体アプリに仕立てることができる。解説( http://cisco.github.io/ChezScheme/csug9.4/use.html#./use:h8 )は商用版の名残りでpetit chez schemeを使っているが、同じことはコンパイラ入りの完全版でも可能なはず。これと言ったフロントエンドの類いは用意されていない、つまり、ユーザは自分でCコードを書く必要がある。
Guileは元々Extension languageとして作られたので当然ライブラリ(libguile)を提供し、ドキュメントも存在する場合はC APIとScheme APIを常に併記している。が、逆、つまりSchemeで書かれたアプリケーションを配布するためにアーカイブする仕組みは備えていない。一応バイトコードコンパイラを直接呼ぶことはできる( https://www.gnu.org/software/guile/manual/html_node/Compilation.html )が、バイトコードを直接ロードする良い方法は無い。...じゃぁ相当量のコードがGuileで実装されているLilypondのようなアプリケーションはどうしてんのかというと、システムにインストールされているlibguileに直接依存する形を取っている。
RacketはたぶんScheme処理系では最も考察が進んでいて、パッケージングツールであるracoがライブラリを含め単体実行ファイルを生成するraco distribute( https://docs.racket-lang.org/raco/exe-dist.html )を持っている。実際の実行ファイルを生成するraco exeコマンド( https://docs.racket-lang.org/raco/exe.html )はテンプレートになる.exeやmacOSアプリケーションのアイコンの差し替えまでサポートしている(UNIXでは単にテンプレートとなるexecutableのコピーになる)。更に、静的ライブラリも同時に提供し、アプリケーションへの組込みも可能になっている( https://docs.racket-lang.org/inside/embedding.html )。
最小公約数としての静的ライブラリ提供
というわけで、Gauche、ChezScheme、Racketは静的ライブラリとして処理系を配布しており、バイトコード化した(または、C文字列化した)プログラムを起動するための簡便なインターフェースを持っていると言える。なので、yuniのSDKとして何か提供するとするならば、
端的に言うとChezSchemeの方式が基準になる。GacuheはCコードの生成、Racketはカスタマイズされた.exeの生成までサービスしているが、アプリケーションに追加の静的リンクライブラリをリンクしたいケース等を考えると、C側のmain()の準備とアプリケーションのリンクは自前でやってしまった方が融通が効くような気がしている。
... 処理系を静的リンクライブラリで配るのか動的リンクライブラリで配るのかはちょっと悩ましい問題で、どちらもpros/consが有る。WindowsやmacOSのように、実行ファイルがPIC(位置独立コード)であることが前提のプラットフォームであれば、静的リンクライブラリで配ってしまって利用者に委ねる方式も取れなくはないが。。特にWindowsの場合、処理系をビルドするのに使用したC言語ランタイムがMinGWなのかMSなのかという問題まであるため、動的リンクライブラリのメリットもそれなりに有ると言える。
yuniが他と比べて特殊なのは、yuniを使うアプリは殆どがネイティブコードを含んでいるという事実で、どうしてもアプリケーションのビルドには追加のビルドツールの存在を想定することになる。このため、ネイティブコード側の処理をScheme処理系に任せたいモチベーションがあまり無い。
Guileのような処理系や、Gambit、ChickenのようなSchemeコンパイラでも同じような方針で単体executableの生成は実装できる。ただGuileのような方式、つまりシステムに処理系をインストールしなければならない方式では、アプリケーションを単体で配布することができない - が、そもそもGuileはWindowsでよく動作しないのであまり大きな問題では無いはず。
