explicit-renaming macroの拡張 の2
モデルから解釈すると、explicit renamingで生シンボルを出力に挿入できるというのは本質的なインタフェースであって、それが処理系にとって都合が悪ければmacro transformerの外でよしなにやってくれ、ということになるんじゃないかなと思います。
もちろんそれはそうなんですけど、処理系の実装を制約するインターフェースは(例えば標準に入れるとしたら)問題があると考えていて、この4引数のexplicit-renamingはギリギリ(プリミティブとして)許容できる最低限なんじゃないかな。と。。Chezやpsyntaxのようにsyntax-caseをインクリメンタルに展開する処理系は困るけど。。
個人的には4引数explicit-renamingの方が対称性が高いので良好に思えるし、syntaxやquasisyntaxを再定義すれば3引数explicit-renamingと(ほぼ)同じ見た目も実現できる。
...もっと政治的な言い方をすれば、4引数explicit-renamingは現状の大体のScheme実装で効率的(かつモジュール対応)に実装できるので、これからライブラリを書くときは、4引数explicit-renamingで書けないマクロを避けるといった使い方をしたい。
syntax-caseの"特殊な"機能
4引数explicit-renamingで書けない重要な要素はidentifierマクロ。これは真にexplicit-renamingやsyntactic-closureのような他のメジャーなlow-levelマクロシステムには無い(多分)唯一の要素で、syntax-caseマクロをモジュールシステムに抱え込まない限り実現できない(importしてきたシンボルがidentifierマクロであることを知らないとマクロ展開が行えない)。これらの概念は直交するものなので、explicit-renamingだがidentifierマクロを持つ実装も考えられる。しかし、syntax-caseでなく、かつ、identifierマクロを持つScheme実装は無いように思える。*1
もちろん、マクロシステムの仕様にidentifierマクロを取り込むこと自体は可能かもしれないが、これを簡潔に実現する上手い方法は思い付かない。。
言い方を換えれば、identifierマクロを使ったライブラリは将来(R"7"RS)ポータブルでなくなる可能性がある。APIを設計するときに、identifierマクロに頼った設計にするのは好ましくないように思える。
もうひとつ、syntax→datumも4引数explicit-renamingでは実装できない。ただ、これはユースケースが思い付かなかった。syntax-caseでは、unwrapのためにこれを使うことがあるが、explicit-renamingではそもそもunwrapなのが前提となっている。
