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

ふみ (DJ Monad) @fumieval

オブジェクト指向向きの言語は、様々な状態とそれに対する手続きを独立した「オブジェクト」に切り離すことができるが、手続きそのものはファーストクラスではない。Haskellの場合は真逆で、好きなように手続きを定義できるが、状態を制御可能にしたまま分離する仕組みがなかった。

ふみ (DJ Monad) @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 @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 「忘れたい」というと、何かつらいことがあったのかな、と思いますね。（実際つらい思いをしてきたわけですが）