キーとしてこれを使うのが妥当かどうかは、よく分かりませんが、元から入っているものなので、自分で同じ様なものを作るよりも良いかと思っただけです。いえばそうでもない気がするので、なるべくC言語のAPIをそのままラップしてそれ以上の事は、もっと外側でやるというポリシーに反するのかもしれません。その辺りを律儀にやって新たなレイアを作るのも、煩わしい気もします。私としては、取れない情報があるわけではないので困り度は低いです。入っていないものは多い様だったので、ひとつひとつ見ていくとアレもコレもとなってしまう気もしました。意味が分かりませんでした。メソッドでできないかな、とやってみたらできませんね。compareが入ってないとobject-equal?も呼ばれないのか。呼ぶようにしてしまうという手がひとつありますが、この問題に関してはハッシュテーブルで比較関数とハッシュ関数をカスタマイズできるようにする、という方が根本的な解決になりそうだと思います。本来はクラスを提供する人が同時に提供すべきで、ユーザが後付けで定義するものではない。addressについてはequal?で比較できるようにしときました。PST言いたい事が2点ありますが、分けて書いても、混ぜて書いても、うまく書けそうにないですが、とりあえず混ぜて書きます。返す様にして欲しい(リストに入れない)。私見では、これはエラー処理が面倒に思える(理由は下の「問題点(case1,2共通)」に譲る)。返す例外などが思いついたが、特に根拠はない(後者は無駄に文字列コピーしてしまうのかも)。いう問題に過ぎなく、特に何も解決していない(と思う)。3回やった方が良い気がする。方がいいかもしれない。ついては、何も考えつかない問題設定について結局、正規表現に過度な期待をしてしまうのと同じ問題ではないかとも思える。データとして#<eof>が返るのは意図したものというよりは実装上の見過ごしと考えてください。#<eof>は入力における異常値であって、途中で#<eof>に出会ったら処理全体が#<eof>を返す、もしくは失敗とすべきです。(これを簡潔に書くにはmonadが使えるといいんですが、それはまた長くなるので置いときます)。予定よりも入力が短いことを許容するなら、それはtemplate側で「こっから先はオプショナル」という指定を入れられるべきで、足りない分についてはデフォルト値を指定するなど。「使い捨てスクリプト」用とするつもりです。真面目にバイナリI/Oを行う方法としては、binary.ioを拡張して構造データを扱えるようにすることを考えています。h)などのアクセサでフィールドにアクセスできます。u8vectorに格納されたバイナリデータの指定のオフセット位置からをheader構造体とみなして各フィールドにアクセスする、など。これが出来たら、binary.packはその上の層として再実装することになるかなと。pack指定文字列をfstruct定義へと「コンパイル」する感じ。今のtrunkの実装はまだ変わると思うのであてにしないで欲しいのですが方針としてはこんなとこです。エラーを表示したいときがあります。実装だとエラーが何も表示されないで終わってしまいます。できれば、フラグ指定でもいいのでエラー表示を行うようにしてほしいです。defaultEscapeHandlerとreport-errorの使い方を自分で書いてて混乱してるようです。defaultEscapeHandlerが設定されている場合にreport-errorがそっちに制御を渡してるのは、多分defaultEscapeHandlerが最終的なエラーハンドリングの振る舞いを決定できるようにするっていう意図だったんだと思うんですが、一方でthread.cでsrfi-18のセマンティクスを満たすためにdefaultEscapeHandlerを上書きした時はreport-errorとの干渉を考えていなかったような気がします。thread.cはdefaultEscapeHandlerを使うんではなく、thread_entryの部分でデフォルトのguardを噛ませるようにすればいいんじゃないかな。mとなってしまいます。(current-module)))みたいな手続き版も提供してあった方が便利な場合もあると思います。実行時にグローバルな束縛を追加してゆくのはプログラムの一貫性という観点からはあまり好ましくないので、わざと不便にしてあります。m)のような、defineが存在しない環境に、モジュール外から束縛を与えたかったので、define-in-moduleを使う必要がありました。この状況(define束縛無し)は滅多に無さそうなので、もし対応するなら、リファレンスのdefine-in-moduleのところに「evalを使えば可能」という事を追記してもらうぐらいで良さそうです。ああ、そういうケースがあるんですね。すればいいわけですが、後から束縛が増えるとなるとそうもいきませんか。evalを使うのは最終手段なので、evalを使うことが自力で思いつける人にしか使ってほしくないなあ、という思いはあります。むー、こういう用途を考えるとむしろdefine-in-moduleを拡張すべきかなあ。設計的に安全なのは、無名モジュールを作った時にフラグによって「モジュールに束縛を注入する手続き」も同時に得られるようにしといて、その手続きを使って束縛を入れて行く、ってのはありそうです。その手続きを手にしていない人には束縛がいじれないと。うーん、なるほどです......。formとして扱ってほしい」パッチを適用した場合、結局、eval越しにdefineを実行できてしまうので、ややっこしい事になりそうです。現在リテラルの正規表現はデフォルトで最適化されますが、これをある程度制御できようになるとうれしいです。ように文脈に依存した最適化がされてしまうとそういった操作が難しくなるからです。