matchを廃止/改名したい

nmosh


なんだか偶にLarcenyでコンパイルしたライブラリが動作しない現象が発生するようになった(Larcenyのバイナリを使ったテストがAppVeyorでだけ失敗する)。常に(yuni base match)ライブラリで起こるので、たぶんLarceny側のexpanderにバグが有るんじゃないかという気がしている。
SchemeのMatchはAndrew Wrightのmatch( http://download.plt-scheme.org/doc/103p1/pdf/match.pdf )が有名で、yuniではAlex Shinnのパブリックドメイン互換実装を取り込んで( https://github.com/okuoku/yuni/blob/3d47da14ffcf1d3528be7c7246189bd49dd9bb5d/lib/yuni/base/match.sls )使っている。
...が、冷静に考えてみると

  • このmatchの豊富な機能をyuniなアプリでは殆ど使っていない
  • この実装はunboundなシンボルにかなり依存しているので ? とかをdefineしてしまうと正常に動作しなくなる
  • yuniは(yuni core)として独自のstructure機能を提供しているのに、それをサポートしていない
  • matchは大抵の処理系でネイティブ実装があるのにそれをブリッジするのではなく独自実装している

という点でライブラリとしては異質な構造になってしまっている。
個人的にmatchはcommon-lispで言うところのdestructing-bindの代替として使っているので、その機能とyuniの提供する構造体(およびペア/ベクタ/文字列)への値マッチ機能だけを抽出したもうちょっとシンプルなマクロを用意しても良いと思う。あとは補助キーワードはScheme標準の =>、else、...、_だけ使うとかyuniのお約束に合わせる必要もある。
問題は match 以外の名前としてどういう名前が適切かというところで、destructing-bindなんてクソ長い名前は厳しいものがあるし、かと言って match という名前を使ってしまうとAndrew Wrightのmatch互換実装を期待されてしまいそうだし。。

  • dispatch - 長いし、yuniのライブラリにdispatch-lambdaが全然別の意味である
  • parse - そこまで高機能じゃない
  • bind - やりすぎ

scanかscan-condあたりか。。yuni固有の事情としては、R5RS処理系上のyuniでは構文はexceptやrenameできないのでscanのような短い名前の構文を標準ライブラリにすると、同名をexportするようなユーザライブラリが書けなくなるという問題がある。まぁ短い名前を使いたければ自分でdefine-syntaxすれば良いのでscan-condかな。。。