CTMCP 6章：明示的状態

明示的状態の導入とそれに伴う色々。

要点

システム構築の原則

　システム構築の原則は抽象化である。抽象化を行うということは、仕様と実装を分けて考えるということである。仕様に意識を集中できることで、それを元にさらに複雑なものを構築したりすることができるようになる。システムを、中心に向かう層の連なりとして構築できるようにするということである。
　システムの構成要素がコンポーネントである。状態を導入することで、コンポーネントは「記憶」を持てるようになる。コンポーネントに「知識」を注入できる、とも言える。そのできることが全て「引数」として外部化されていた宣言的モデルにおけるコンポーネントとは違い、状態をもつコンポーネントは「成長」させることができる。
　既に見たとおり、宣言的モデルに並行性を持たせることでも、ある側面から見た「記憶」を持たせることができるようになる。ストリームオブジェクト、ポートオブジェクトがそれである。並行性による状態の実現は、明示的状態を導入するのと違い、プログラムの各部分が全順序の依存関係を持たないという利点がある。別の見方をすれば、明示的状態は、並行性を導入することなく、コンポーネントに「記憶」を持たせることができるようになる、とも言える。

明示的状態（explicit state）

　まず、状態を次のように改めて定義する。計算の入出力のみではなくその途中に注目していることに注意。

　状態（state）とは、必要とされる途中の計算結果を含む、値の時系列である。

　明示的状態を導入する動機は既に述べたとおり。計算モデルに値可変格納域という新たな格納域を追加する。
　これは「コンテナ」、「代入」という概念を導入することであり、これによって、値が時系列化し、「状態」が表面化する。（抽象的な立場を貫くのであれば、明示的状態とは、ある「識別子」が指し示す「値」が、別の「値」に付け替えられる、ということであり、「値」自体が変化するということではない。）

データ抽象の必要性

　状態を導入するということは、プログラムの各部分が、別の部分から見える状態を自由に変更できるようにプログラム可能になるということである。このようなプログラムは非常に推論しにくい。であるから、状態はカプセル化と一緒に使うのが有効である。こうすることで、独立に推論することが可能になる。
　カプセル化を行う、ということは、手続きをデータと一緒に使う、ということに他ならない。データという抽象的な型と、それに対する操作を知れば十分になる。この有用な形の発展として、オブジェクト指向プログラミングが現れる。

本章の計算モデルの限界について

　本章の計算モデル（オブジェクト指向プログラミング含む）は直列であるため、現実の並行性をうまくモデル化できない。そういうものの解決として一つには前章で見たメッセージ伝達並行モデルがある。のちに、これとは別の、状態共有並行モデルを見る。

感想

　宣言的モデルに、なぜ明示的状態を導入する必要があるのか。明示的状態がなぜオブジェクト指向に導かれるのか。
　関数型やオブジェクト指向の良い部分の独立した説明はたくさんあれど、その他の計算モデルとの対比や、あるモデルが別のモデルを取り入れる動機の説明ってなかなかなくて、それがこの本に書かれていて良かった。なのでその点を重点的にまとめてみた。実際の中身としては、上のような抽象的な話にとどまらず、大規模なシステムの設計に際してのコンポーネントの扱いから依存性の情報の扱い、開発の進め方、とかまで話が及んでいて、読み応えある。
　あと面白いと思ったのが、宣言的モデルの上で可能な技法をすでに一通り見てるから、明示的状態を導入したというだけでは、それほど本質的に説明すべきものがないという点。技法の基礎を説明するシンプルなプログラミング言語としてしばしば明示的状態を持つCが想定される（ようなイメージがある）けれど、実はその多くはもっと単純な計算モデルの上でも成り立つものだ、という勝手な理解を得た。

演習問題

つまみ食いになってきてる。
https://github.com/Altech/ctmcp-answers/