後で真面目に考える為のメモ。今日昼ご飯を食べていて、画面表示アーキテクチャの話になった。画面表示には色々面白い問題があるけど、要するにやってる事は、あるデータに連動してそれを表現する為の表現を生成する事。データが変更されれば表示も変わらないといけないし、ユーザが GUI からデータを変更しようとするかも知れない。これをもっとちゃんと作れないかという物。
繰り返されてきた話題だけど、勿論私には答えなど分からない。だけどもやもや感じるのは、とある二つの見方を結びつけたら良いんじゃないかという事。一つはオブザーバパターンで、MVC なんかに使われる更新メカニズム。オブザーバパターン自体は粒度が小さいので、組み合わせ方に設計上のトレードオフがある。もう一つはラムダ計算。
ラムダ計算とは、もうこれ以上無いというくらい単純化した計算モデルの一つだけど、ラムダ式は「他の値に依存する何か」を考えるのにも最適な方法に思える。ただ、単純すぎてオブジェクト指向に必要なアイデンティティという物が無いので、オブジェクト指向的な意味での「同じ」未来のオブジェクトを指すポインタを一つ必ず持つ物(ストリーム)を基本要素にすれば、オブザーバーパターンを構成出来る。ここで、後で考える事。
- ストリームとオブザーバーパターンは同じ物か？
- オブザーバパターンをストリームで実装して利点があるか？(利点があるのは自明なので、実際に人間と機械双方に最適化するデモをしてみる)。
- オブザーバーパターンを機械的にストリームに変換出来るか？
- http://ja.wikipedia.org/wiki/Observer_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
- http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97
- http://d.hatena.ne.jp/propella/20070129/p1
具体的にはどういう事か？
さすがにこれでは訳分からん感じなので、別の方向から書いてみる。ラムダ式が何故重要かは次の理屈。
- お互いに依存する状態群を表現するプログラムを作りたい。
- 状態群の関係を書けば、その最適な実装(キャッシュを作るか、ポーリングするか、通知メカニズムを使うか等)はコンピュータが最適化して欲しい。
- コンピュータが最適化するためには、実装が違っても答えが同じ事を保証しなくてはならない。
- ラムダ計算の、計算の経路が複数あっても答えが同じである性質(チャーチ-ロッサー性)を使う。
また、豆知識として、全てのデータ構造はコンスセルで表現出来る -> コンスセルはラムダ式で表現で出来る -> 全てのデータ構造はラムダ式で表現出来る。というのもポイントです。
次に、理屈ではラムダ式が役に立ちそうだと分かっても、実際に応用出来なくては意味が無いので、オブザーバーパターンをラムダ式で表現する定石を探しているわけですが、特にストリーム(car の要素の型が同じコンスセル)はよく知られたデータ構造なので、これを使うわけです。
さらに、実際に etoys の簡単なデモ、例えば車がぐるぐる回転するようなプロジェクトで、車の角度(例: "45度")の表示は実際の角度情報(例: 45度)に依存していて、角度情報は角度ベクトル(例: 0.7@0.7)に依存していて、という依存グラフをラムダ式で表現して見る事を考えています。
ぶっちゃけ、FRP をオブジェクト指向の言葉で説明しなおすに過ぎないかもですが、言葉というのは重要なので説明しなおすだけでどれだけ印象が変わるかという事に興味があります。
