もにゃど的アダプタ

あ〜,くそぉっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃどをちゃんと理解してて,あと関連するプログラミング言語・理論あたりについてきちんとサーベイすればある程度のとこに出しても恥ずかしくないレベルの何かに仕上げられる気がするのにっ!!のにっ!!

  • 合成可能なアダプタ,あるいはそれに類似の概念は何らかの汎用な形に formalize できる.既存の C++ のライブラリ実装で体現している具体例としては Boost.Lambda, Boost.IteratorIterator アダプタ群, RangeEX のアダプタ群, Boost.Iostreams (の Filter)など.あと個人的に思いつく範囲としては PropertyMap に対するアダプタ,他 GUI など Decorater パタンが適用できる領域, Proxy パタンが適用できる領域とか?
  • 特にある Category C の Model m と,C におけるアダプタ a (m に a を適用した結果がやはり C の Model であるよ〜な a)が与えられたときに, m に a を適用する,あるいは a と a' を合成するっつー演算を考えると,なんかやってることがめちゃくちゃもにゃどっぽい(異なる Category に飛ばしても O.K.?).でも「Monad っぽい」だけで終わるのはすでにブログレベルですら(びみょ〜に)指摘している人がちら ほらいるのであんまし面白くない.ちゃんと formalize したい. formalize して Monad 合成とかもっと斜め上なとこまで行きたい.けど,これをどう formalize したら良いのかがじぇんじぇん分からにゃい.ちなみに複数のアダプタの合成は結合則を満たすので,複数のアダプタを合成した(これもやはりアダプタ)オブジェクトを先に生成しておいて,これをいろんな Model に適用するっちぅ使い方もふつ〜に可能
  • 考え方としては FOP っぽい?(<- さっき検索してたら引っかかったっぽ)ってか,これの考え方をきちんと(C++ における) Generic Programming の用語(Category, Model, Valid Expressions, e.t.c.)を使って Monad (composing monad?) の形で formalize したいのにゃ!!
  • アダプタに関してコアな部分だけ書けば,アダプタオブジェクトとベースとなるクラスのオブジェクトの間の相互作用,あるいはアダプタオブジェクト間の相互作用は(もにゃど則に従う)合成演算に隠蔽できる.例としては Boost.Iostreams の Filter で,あれは Filter の機能については最低限のことを書くだけで済ませて, Device と結合したり Filter と合成したときのバッファ管理などは合成演算に隠蔽してる
  • C++ だと Expression Template を用いて(演算子による中置記法で)手続き的に書けるシンタックスシュガーを提供できる
  • この勢いなら書けるっ!!いまさらながら『かしまし』萌えぇ〜.っていうか一人真性な娘さんがいらっしゃいますががが.だがそれがいい……
  • さらに C++ においては合成の演算は compile-time で行え,また任意の粒度で type-erasure を用いて合成の結果の複雑な型を消去し run-time polymorphism を獲得できる.この結果, primitive なレベルの feature の合成で run-time polymorphism によるオーバーヘッドが許容できない粒度では compile-time の合成のみによって効率を維持し,かつ(feature composition の結果)ある程度以上の粒度に成長して run-time polymorphism による実行時オーバーヘッドが相対的に許容できるようになった時点で type-erasure を適用して run-time polymorphism を獲得しかつコンパイル依存も切って通常の Object-Oriented Programming の formalism に切り替える,ということが非常に容易に行える(前々からやって欲しいやって欲しいと書いていた「Compile-time Polymorphism と Run-time Polymorphism の柔軟な行き来」の1つの体現).もちろん先に合成したアダプタのみについて type-erasure を適用して,そいつをいろんな Model に適用する芸当ももちろん可能.この形態の既存の例としては Boost.Lambda + Boost.Function とか(あんまり良い例じゃにゃい)? Boost.Iostreams の chain もそーだよねー.

う〜う〜う〜う〜. IFPH とかいろんな Haskell まわりの文献を,上の formalization を Monad の言葉を使ってなんとかしたいっつーモチベーションのため(だけ)に読んでるのに全然ぜんぜんぜーんぜんずぇーんずぇん分っかんにゃいーぃっ!!!専門家じゃにゃいのでどこら辺の論文漁ればよいのかもじぇーんじぇん分かんにゃいっ!!!
これが形になれば「Template Metaprogramming + Generic Programming + Functional Programming (Monadic Programming) で Object-Oriented Programming かつ静的・動的多相の柔軟な切り替えを実現して,まさに Multi-Paradigm わはー♪この水準の Multi-Paradigm Programming を現行の言語規格で提供できるプログラミング言語C++っ!!」とかってでっち上げられるはずにゃのにぃーっ!!