状態、型、抽象化についていろいろ

とりあえず。まとめ。誰でも編集可、編集自由にしますので、是非、適当に追加してください。
プログラミング オブジェクト指向 関数型言語
16
ふみ 🐦☀💧🌳 @fumieval
オブジェクト指向向きの言語は、様々な状態とそれに対する手続きを独立した「オブジェクト」に切り離すことができるが、手続きそのものはファーストクラスではない。Haskellの場合は真逆で、好きなように手続きを定義できるが、状態を制御可能にしたまま分離する仕組みがなかった。
ふみ 🐦☀💧🌳 @fumieval
…というのを昨日山本さんに話した。これが従来のOOPの世界とHaskellのスタイルの間にある地溝で、ここに橋をかけない限り、状態について不自由が発生し続けるだろう
m2ym @m2ym
いつから型があって次にコンストラクタがある、という考え方になったのかを考えるとちょっと面白いかもしれない
m2ym @m2ym
そういう風に作ったほうが理論的にも実装的にも楽だった、という面が大きそう。実際それだけでも十分うまみがあったのだろう
pokarim @pokarim
先日、m2ymさんとの議論の中で、「状態を持つのがダメ」なのではなくて「状態遷移を明示的に表現するのがダメ」なのではないかという表現がでて、まさにそのとおりだと思うので、有り難く頂戴して今後使っていきたいと思う。
pokarim @pokarim
例えば、 b = a * 2 と書かれたコードがあったとして、b や a が、不変な値なのか、 そうではなくて時間変化する値、FRPのBehavior的なものなのかは、 コードの見た目からは区別できない。 これはもう少し長めの関数プログラミング的なコードがあったとしても同じ。
pokarim @pokarim
状態そのものが悪いのではなくて、例えば再代入や破壊的なメソッドを呼ぶコードこそがモジュール性を阻害する。たとえ状態遷移を関数的に記述したとしても、その望ましくない性質は消えない。
pokarim @pokarim
なので、状態があれば良くなくて、純粋に関数的ならば良い、というのは誤りだと今は考えている。
pokarim @pokarim
@pokarim 誤りというより、ちょっと乱暴すぎて穴がある。
pokarim @pokarim
手続き的なコードを、persistent data structure と、IOモナド、Stateモナドを使って機械的に翻訳することは可能だが(そしてそれだけでも最低限の利益が無いわけではないが)、そのコードは表面上関数的であってもあまりよくないコードとされるだろう。
pokarim @pokarim
それがなぜかと言えば、状態遷移を明示的に記述しているからだ、と今は言うことができる。
pokarim @pokarim
そしてこれが関数プログラミングの文化のなかから FRP が生まれてきた理由だと推測できる。
pokarim @pokarim
すでに実用されていて、状態遷移を明示的に記述せずに状態を扱うことを可能としているものとして、マテリアライズド・ビューの技術があると思う。基底テーブルに対する変更操作は破壊的だが、ビューの持つ状態の遷移は明示的に記述されず、暗黙的に処理される。
pokarim @pokarim
そう考えていけば、あらゆるキャッシュもすべて同じ性質を持つけれども、キャッシュが問題を引き起こすのも、破棄のタイミングの管理の難しさだと考えると、キャッシュ自体は暗黙的にできてもその破棄(つまり状態の遷移)を明示的に書かざるを得ない場合があり、それが問題なのだと言える。
pokarim @pokarim
マテリアライズド・ビューも、そのリフレッシュのタイミングに気を使わざるを得ないという状況では、リフレッシュという状態遷移を意識せざるを得ないということなので、その良さが半減すると考えられる。
日本のリアクター @mizchi
ユーザーのメンタルモデルは副作用ありますよ
pokarim @pokarim
ユーザから見て、システムが可変な状態を持っているような振る舞いをするのが自然な場合はとても多い。
pokarim @pokarim
このことと、コード上、状態遷移を明示的に記述しないようにすることは、まったく矛盾しない。
pokarim @pokarim
そのことは、Excel の素朴な使い方を考えてみればわかる。エンドユーザがセルに書き込んだ数式は、状態遷移についてまったく触れていない。ユーザは基底となるセルを自由に書き換え、それに伴って数式を含む導出的なセルは自動的に書き換えられる。
pokarim @pokarim
ユーザの書き込みを受け取り、導出セルの更新を行うのは、処理系つまりここではExcelそのものの仕事。数式は、それらの状態更新について関知しないしそもそも関知できない。
pokarim @pokarim
ユーザが直接的に、何かを追加したり変更したり削除したりしようとすることそのものは全く問題ない。しかし、それに伴っておきる付随的な状態の変更や副作用、例えばキャッシュやインデックスやサーバへの通信などは、明示的な状態遷移や副作用を記述せずにすませることが望ましいということ。
pokarim @pokarim
@pokarim ここらへんは、明らかに説明が無駄に込み入っているので、もう少し理解が進んだらより良い説明ができるようになると思う。
pokarim @pokarim
つまり、ここはユーザが直接触って書き換える状態ですよ、と書いておくことは問題なくて(この状態遷移は処理系が行うから)、その状態に依存して書き換わっていく他の状態の遷移を明示的にコードとして記述することが、モジュール性その他を阻害するということ。
pokarim @pokarim
しかしここで、ユーザは、自分が見ているものを書き換えようとするので、Viewの変更を規定となる状態への変更に変換する作業は、処理系が行う必要がでてくるだろうと思われる。つまりFRPでいう双方向性やRDBMSでいうViewのUpdateに相当する何かがおそらく必要とされる。
pokarim @pokarim
@naka_aki_spl 「忘れたい」というと、何かつらいことがあったのかな、と思いますね。(実際つらい思いをしてきたわけですが)
残りを読む(292)

コメント

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz 2014年12月9日
それっぽいの、ついかしました。まとめを更新しました。
はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz 2014年12月9日
追加しますた。まとめを更新しました。話が発散しすぎてますが、たぶん個人的にまとめます。
はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz 2014年12月9日
洗脳と啓蒙関連ツイートと、圏論の話は削除しました。まとめを更新しました。
はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz 2014年12月9日
なんかツイートが足りない気がするので、気がついたら追加しますー。
ログインして広告を非表示にする
ログインして広告を非表示にする