週刊nmosh - issue管理行き
yuniの移植過程で出た問題をGitHubのissueに入れていくことに。
現時点で12件有るこの前途多難ぶり。。これからFFIを入れはじめたらどうなってしまうことか。。
例えば https://github.com/okuoku/yuni/issues/1 とか https://github.com/okuoku/yuni/issues/2 のように他所の処理系の問題であってもyuni側にも起票し、対向するバグ票にリンクする形で。
タグはかなり積極的に使用している:
- https://github.com/okuoku/yuni/labels/Extern-IssueTrack
- 処理系のバグ
- https://github.com/okuoku/yuni/labels/Extern-WARTrack
- 処理系の仕様に起因するワークアラウンドを行っている
- https://github.com/okuoku/yuni/labels/Extern-Blocker
- yuniの移植をblockしている課題(これも含め、yuniのissueは必ずしもbugでは無い)
GitHubのissuesは他所にエクスポートしたり他のシステムとの連携が柔軟にできないので、あんまり積極的に使うものでもないような気もする。一種のベンダロックインとも言える。
今週のissue
というわけで起票したもの全部を挙げると大変なことになるので適当にピックアップ。
- https://github.com/okuoku/yuni/issues/11
- Chicken: Aux-keywords are not bound in (scheme base)
Chickenはr7rs eggでR7RSのライブラリ構文をサポートしているものの、... とか _ のようなSchemeで使用される補助構文がどこのライブラリにも無い。このため、yuniのように(scheme base)をエイリアスするライブラリを書くことができなくなってしまう。
yuniではR7RS標準の補助構文はリネームしてはいけないというローカルルールを設け、chickenのような実装の場合はexportから外すことで対応する。(GaucheやSagittariusでキーワード風のシンボルをexportから外すのと同様。)
- https://github.com/okuoku/yuni/issues/10
- Chicken: No way to implicit-export macros
もっと深刻なのは、Chickenのexpanderはモジュールで定義した構文を明示的なexportなしではモジュールの外で展開させられない点。これはGaucheに起票した問題 ( https://github.com/shirok/Gauche/issues/42 )の拡張で、構文のスコープがかなり制約されることになる。
マクロを分割して定義したいだけならば、(ネストは深くなるものの)let-syntaxを使った記述に置き換えることで多くの場合は対処できる。しかし、issueに書いたコードのように、"define(-syntax)で導入する束縛のbody部分で使うマクロ"をマクロで導入することはlet-syntaxではできない。
原理的には、全てをexplicit-renamingマクロで書き直し、毎回全ての中間マクロを(gensymして)インスタンシエートすれば良い。ただyuniはsyntax-caseな処理系と実装を共有している都合上、syntax-rulesの枠でこれが書けないと困ってしまう。
これをサポートすることにはトレードオフが有る; expand済みのライブラリをキャッシュするようなケースでは、exportしていないものも含めて全てのマクロ展開コードを保持する必要が生じる。Chickenのようなセマンティクスは、明示的にエクスポートされていない構文の展開コードは保持する必要が無い。これを良くサポートするには、nmoshのようにexplicit phasingな処理系とする必要が有る。
R5RS / R7RS枠でライブラリを構築することの難しさ
というわけで、yuniを始めてみてわかったのは、マクロを多用しつつR6RS / R7RSハイブリッドなライブラリを構築するのは思いの外難しいという点。(SLIB以外の)他所のSchemeライブラリがあまり複数の処理系に対応していないのも頷ける話というところか。。
- https://github.com/okuoku/yuni/issues/13
- (yuni base match): match uses _ as syntax-rules literal
例えば、R6RS処理系ではsyntax-rulesのリテラルに _ を使えない。しかし、chibi-schemeでは普通に使えてしまう。SRFI-46なsyntax-rulesは ... を置き換えることができるが _ を置き換えることはできないので、事実上 _ を含む構文をポータブルに記述する方法が無くなってしまう(原理的には _ をlet-syntaxで差し替えることで記述できるが...)。
なんともバッドノウハウ的だが、Schemeライブラリをポータブルにするには可能な限りマクロを避けた方が良いのかもしれない。