yuniの目標設定をする会

nmosh

yuniはかなり複雑なプロジェクトなので、ちょっと目標をブレークダウンして他の処理系に影響しそうな項目を先に済ませることにした。
ここに入れていない重要な問題はドキュメンテーションのインフラで、良いエディタが見当たらないまま今に至る。もうSeamonkeyでHTMLを書いて適当にDITA変換とかで妥協すべきか。。

目標0: public domainにできないファイルを除いてヘッダにCC0を書く

特にIssueは起票していないが、yuniはCC0(Creative commonsのpublic domainライセンス)を採用したいのでそのクリアランスをリリース前に済ませる必要がある。
C++のテンプレートライブラリ同様に、Schemeのライブラリもimportして使ったら派生物なのか問題が有る。個人的には処理系間で共有されるライブラリは(その実装形態を制約しないように)R6RS/R7RS報告書と同じライセンス形態にすべきだと考えていて、それを達成できるメジャーなライセンスがCC0ということになる。
テストはインストールできないのでCC0の対象外。というかライブラリの一部でもない。

目標1: 各種処理系用のローダーを書く

yuniを使用したアプリケーションを実行するためには、yuniのライブラリを動的にevalで読んできて実行するためのwrapperが必要になる。というのは、Schemeにはライブラリファイル配置に標準が無いため。
例えば、chickenとかpicrin用には専用のローダーを既に書いている。これはR6RS書式のプログラム/ライブラリのimportを解釈して適当なライブラリを探してloadしてくるようになっている。

同じコードが他のサポートしている全てのScheme処理系用に必要になる。R7RSでは(scheme repl)ライブラリとしてこの手のloadを処理できるようになっているが、R6RSには標準は無いので適当にhackする必要がある。
このようにyuniのアプリはloaderを使って実行するのが基本になるので、yuniは意図的にR7RS libraryフォーマットを避けている。R7RSのライブラリ構文にはincludeのように曖昧( https://github.com/okuoku/yuni/blob/049d2bff91fd3f945de4d4e7780d1626f82965b3/doc/sibr/SIBR0005-C-STYLE-INCLUDEPATH.md )な定義が存在するため、yuniで何かライブラリ挙動を規定してしまうと、ホストSchemeのR7RSライブラリ挙動と衝突してしまう可能性がある。
アプリケーションローダーは、アプリケーションをいくつかのSchemeライブラリに分割して記述することをサポートするが、そのライブラリをsite packageとしてインストールする機能は持たせない。別にyuniはyet anotherパッケージマネージャを目指しているわけではないので。ただし例外はFFIパッケージで、FFIバインディングは各種処理系で共有でき、かつ、既存のパッケージマネージャではよく管理できないので将来yuniで統一したライブラリ管理ツールを用意する可能性がある。

目標2: SDL2上のPONGを動かす

yuniの営業上の価値は"各種Scheme処理系で共通の静的FFIバインディングを提供する"点にあるので、当然、それを使ったサンプルを何か提供することが望ましい。
まぁPONGくらいなら直ぐ書けるはずで、問題はビルドシステム。yuniをテストするためのDocker imageであるyunibase( http://d.hatena.ne.jp/mjt/20160222/p1 )はSDLを含んでいないので、

  1. yunibaseをSDLを含むように拡張する
  2. SDLのような外部ライブラリを含んだ別のイメージを定義する

の2択になる。美しいのは後者だが、これをやってしまうと管理すべきイメージの量が増えてしまうのでyunibaseが"全部入り"であることをキープしようかと思っている。どうせ現状の1GiB程度あるイメージサイズからさらに縮小することは困難なので。。

目標3: 各種処理系用のパッケージを用意する

処理系によってはライブラリパッケージのフォーマット仕様を規定していることがあるので、それに従ったパッケージを用意する。
たぶんこれが一番面倒な作業で、処理系毎にパッケージシステムがカバーする範囲やマニフェストの記法が異なっている。あと、Gambitのように有力な処理系でもパッケージマネージャが無いこともある。nmoshにもパッケージマネージャはないが、nmoshにはyuniを標準添付するので大きな問題ではない。。
Guileは標準のパッケージマネージャが無い。今のところ有力そうなのはGuildhall(dorodangoの移植: https://github.com/ijp/guildhall )なので、これへの対応を検討する。...でもただでさえ長いguileのビルド時間に、更にパッケージマネージャのビルド時間が掛かるのか。。
RacketとChickenは標準のパッケージシステムが直接Gitリポジトリを取り扱える。もっともどちらも専用のレイアウトが必要なので、リリース用のリポジトリを別途確保することになる。
GaucheとSagittariusはそれぞれgauche-packageやsagittarius-packageを持っている。もっとも、SagittariusではFFIにネイティブライブラリは不要(FFI機能は組込みのlibffiを使う)のでこれといってパッケージしたい要求は無い。というわけでsagittarius-packageは使わず、直接sagittarius-configでパスを得てCMakeLists.txt内でインストールする。
chibi-schemeではsnow-chibiがパッケージマネージャとして提供されている。これは更にLarcenyやkawa、Gaucheといった他のR7RSもサポートしているという触れ込になっている。(試していない)
これ以外の処理系ではCMakeLists.txt内で適当に判別してインストールすることになる。