週刊mosh - 0.2.7リリースブランチマージ / WG1への対応方針

0.2.7のリリースブランチ(okuoku側)が開発ブランチ(higepon側)にマージされました。
moshはそれなりにテストが有って、0.2.6→0.2.7の変更でビルドの信頼性は相当向上したので今後は(pushする前にcheckさえすれば)開発ブランチとリリースブランチの別は無くなるはず。。
このマージによってディレクトリ構成が変更されたので、gen-git-build.shの前にgit cleanするかcloneしなおしてください。autoreconfがlibtoolizeを実行しないことが有るので事件が起きます。

解決したIssue

with-syntaxにbodyが無い。これは、psyntax-moshもnmoshもSRFI-93の定義で実装していたため。
psyntax-moshはパッチが提供された。nmoshはR6RSのexample通りの定義に変更。
この辺の変更はr6rs-test-suiteにフィードバックした方が良いかもなぁ。。

mergeされた。

報告されたIssue

mosh上で使えるScheme手続きはCProcedureと呼ばれる。このScheme手続きの戻り値はCProcedureオブジェクト中に保持されるのを期待しているので、本来CProcedureの呼び出しからそのCProcedureに再帰することはできない。
これが起こるのはCustom portsとhashtable、FFIだけなので、これを全部VM側のディスパッチループでチェックして特別対応する必要が有る。今のところ、put-stringとFFIだけが対応されているので、Known Issue行き。
個人的には、これはdesign flawだと考えていて、(CProcedure的な意味で)Leaf functionでないCProcedureを作らないようにする(= Custom portsScheme側で実装する)か、そもそも現状のVM自体を再編する必要が有るような気がしている。

話題

0.2.7から、正常に動作するSRFIが必要になったという話。これに関しては対策を2つ考えていて、1) gen-git-build.shの中でLOADPATHを空に再設定 2) bootstrapに使うmoshをnmoshに変えて-nodefaultlibのようなオプションを追加。
psyntax-moshは(この界隈ではメジャーな)Derick EddingtonのR6RS SRFIコレクションを実行できないバグが有る(コンパイラのバグを踏む)。nmoshは実行できるのでそちらの方が安定すると期待される。

Socketからの送信時にSEGV。GCの問題ではないかと考えられる。
nmoshはそもそもサンプルを実行できないので、nmoshのバグの予感も。

CMakeビルドからpsyntax-moshdrop

0.2.7から、CMakeビルドではpsyntax-moshが作れなくなります。Loadpathの挙動調整やbootstrapが難しいことによる問題。
configureによるビルドでは従来通りpsyntax-moshが標準。

組込みモード / prefix-less モード

prefix-lessモードはライブラリを$PREFIX/share/mosh/$VERSION/libから探さないモード。
組込みモードは、share/mosh/$VERSION/libの構造自体を使用しないモード。/libの代わりに/mosh-libにSchemeライブラリがインストールされるように。(後者は未実装)
これらはWin32やMac OS Xのアプリケーションとしてnmoshを使うためのモードで、システムに他のnmoshがインストールされていても干渉しないようにするのと、インストーラによってprogram files以外にmoshがインストールされた場合の対策。

psyntax-moshのnmoshによるBootstrap

psyntax-moshはnmoshでbootstrapできるようになりました。(未merge)
現在、psyntax-moshSubversionから常にダウンロードする方針になっているのを、nmoshと同様gen-git-build時に生成するよう変更可能に。
ただ、現状のnmoshはpsyntax-moshでbootstrapしないといけないので、この点をどうにかする必要有り。高速化のためにGaucheを使ったbootstrapを以前無効化したので、それを復活させるかも。
bootstrap時に外部と通信するプログラムは、実際のアプリケーションに組込むという観点から言うとかなりヤバいので。。

テストケースから外部通信の排除

FacebookGoogleといった外部サイトと通信を行うテストケースは一旦全部無効化しています。プライバシの懸念のため。
今回は手動でtest suiteを検閲したので、人工的にテスト環境を調整してチェックする必要が有った。将来的には自動化する必要が有るかも。

nmoshのWG1 modulesへの対応(予定)

(psyntax-moshの対応方針は不明)
nmoshはWG1 modulesに対応する予定です。これは将来のScheme標準のproposalで、includeを標準で持ち、exportやimportを好きな場所に配置できます。

nmoshとして拡張するのは :

  • phase semantics。R6RS互換のPhasing機能。
  • includeは文字列だけでなくDerick EddingtonのR6RS SRFIコレクションに見られるような(directory filename)形式のオブジェクトにも対応。この形式で指定した場合はライブラリと同様に検索される。
  • includeされたファイルもキャッシュ依存関係として追跡する。
  • 拡張子は.slsに限定。.nmosh.slsを推奨。
  • SRFIライブラリはSRFI-97互換名のエイリアスを持つ。現状のmoshで提供されているSRFIはほぼ対応予定。
  • いくつかのR6RSライブラリは提供される。(rnrs base)や(rnrs control)、(rnrs unicode)等。
    • (rnrs base)のsyntax-rulesはchibi-scheme由来のもの。

重要な注意点としては :

  • WG1モジュールライブラリを使ったプログラムではsyntax-caseとR6RS recordが提供されない
    • 平たく言えば、(rnrs)は提供されない。(rnrs base)や(rnrs control)を明示的にimportする必要有り。
    • low-level macrosとしてはexplicit-renaming+とその上に実装された普通のexplicit-renamingを提供します ( http://d.hatena.ne.jp/mjt/20110302/p1 )
    • マクロの結果としてシンボルを返した場合の挙動は、普通のexplicit-renamingは適当なidentifierの挿入(= 〜+におけるinject)、explicit-renaming+の場合は未定義です。(内部的にVMコンパイラ用のcore-form挿入に使用)
  • 最初のバージョンでは(rnrs base)のidentifier-syntaxは提供しない予定。
  • 標準的なScheme bindingは(rnrs)でなく(nmosh)で提供される。これにはSRFI-8やSRFI-26、SRFI-48、(shorten)のような基本的な構文や手続きも全て含まれる。(Chez Schemeにおける(chezscheme)ライブラリと同様の方針。)
    • (mosh)で無いことに注意
    • (nmosh)はR6RS版も提供し、これにはincludeやbody構文も含むので、R6RS実装と互換性のあるライブラリを記述することも一応可能。
  • バージョン機構は提供予定なし。現状と同様。
  • ReaderはR6RS互換。ただしcase-foldingなし。

現在、WG1はドラフトを作成中なので、それを待っているところ。
とにかくsyntax-caseが難しいところで、これさえサポートできれば現状のnmoshのexpanderは廃止できる。それまでは、WG1 expanderと現状のnmosh expanderの両方を持つことになる予定。。
一応、explicit-renaming+の仕様はsyntax-caseと同居できるように作ってあるので、それなりにコストを掛ければ対応すること自体は可能。問題は、そこまでコストを掛ける必要が有るかどうかというポイント。。
手元のプログラムにおけるsyntax-caseのユースケースは、explicit-renaming+とmatch構文の組合せでほぼカバーできるので、個人的にはWG1 expanderが安定したらnmosh expanderは使わなくなるような気がする。