週刊nmosh - callbackとディスパッチの抽象化

R7RSは成立する見込みでnmoshとしても対応を本格化しないといけない時期。プリプロセサとして内部でR7→R6変換するのが楽かな。。ライブラリはdefine-valuesのバグを治したり、算術系のバグがおおいのをどうにかしないと。

Q: (R7RSの)syntax-rulesは ... を置き換えられるのに _ を置き換えられないのは何故？

A: そんなことを言うのは君が初めてだ

http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003507.html

> By the way, I wonder why we can't specify an alternative for the
> underscore, while we can specify what to use as .
Nobody thought of it for three years.

まぁ ... と違って _ は使わずに済ませられるからかなぁ。

callbackとディスパッチの抽象化ライブラリを作りたい

prev: http://d.hatena.ne.jp/mjt/20130203/p1

nmoshはライブラリのスタイルとしてcallbackを多用している。つまり、I/Oのような非同期オペレーションの結果を受け取ったり、UIフレームワークでのイベントハンドリング等が全面的にcallbackスタイルで書かれている。
なので、デバッグの時も、callbackに渡される引数(= メッセージ)をdisplayなりpretty-printする機会が非常に多いけれど、これをシステマティックに導入したい。
しかし、callbackは一般的に無名関数なので、特定のインスタンスに対するcallbackを指定してdebug文をON/OFFするのがなかなか難しい。というわけで、callbackとして渡された手続きに名前をつけて管理したり、その継続に渡される値をdumpしたりfakeしたりする仕組みを作りたい。

単機能のcallbackとディスパッチ

非同期I/O手続きに渡すcallbackは基本的に単機能で、readしたバッファ(か、失敗した場合はエラーコード)を受け取る。これにくらべて、GUIのイベントハンドラは、一つの手続きで複数のイベントを処理することを期待している。
設計のシンプルさという意味では、GObjectのsignal/connectのように、名前付きのcallbackスロットにディスパッチを伴わないcallbackを一つ一つ入れていくスタイルのほうがシンプルで分かりやすい気もする。
それでもフレームワークでディスパッチをサポートしたいのは、IDEサポートのため。あるオブジェクトから発生する可能性のあるイベントをまとめて列挙しておくことはライブラリの理解のために有益なヒントになる。これを実現するためには、ディスパッチに対する統一的なintrospection手法が必要になる。
ディスパッチのセットをCOMのようにインターフェースという形に纏められると便利かもしれない。つまり、一つの手続きが複数のインターフェースを提供する等。