オブジェクト指向の理論

イカ娘 @came_tongue_000

@omasanori 了解でゲソ。

Masanori Ogino @omasanori

@cametan_001 まず、CPSとアクターについて振り返ると、「計算の続き」を明示的に受け渡すような仕組みになっていれば、「値を返す」だとか「スタックにpushしてpopして」だとか考えなくてもよくなるというのがCPSの一つの見方だと思います

Masanori Ogino @omasanori

@cametan_001 関数は値を受け取って値を返す一方で、アクターは新しいアクターを作ったりメッセージを別のアクターに送ったりします。CPSで「計算の続き」を扱うと、関数とアクターの関係が見えてきたぞ……というのがSussmanとSteeleのSchemeにつながるわけです。

Masanori Ogino @omasanori

@cametan_001 「レキシカルクロージャと書き換え可能なセルがあればオブジェクトを表せるよ」という話をCPSとアクターの視点から言い換えると「レキシカルクロージャと書き換え可能なセルがあれば状態を内部に持つアクターを表せるよ」ということになります。

Masanori Ogino @omasanori

@cametan_001 逆に言うと、レキシカルクロージャがないと状態を内部に持つアクターを表すのがどうも難しい、不便だということで、Schemeが全面的にレキシカルスコープを採用したのもそういった事情があるのではないかと考えています（裏付け取れてない）

Masanori Ogino @omasanori

@cametan_001 といったところで次はOOP。まずSmalltalkとアクターはどちらが先なのかというのは「アクター理論の原型に影響を受けて初期のSmalltalkが生まれ、その影響を受けてアクター理論が現在の形になった」というのが実際のところだろうと思います

Masanori Ogino @omasanori

@cametan_001 先ほど「アクター理論の原型」と呼んだのはPlannerです。Plannerの設計者Carl Hewittはアクター理論の提唱者で、PlannerはSchemeの名前の由来としても知られています。Planner自体はアクターに基づいていません。

Masanori Ogino @omasanori

@cametan_001 SchemeはSmalltalkやアクターよりも後に生まれたので時系列としてはあべこべですが、レキシカルクロージャと書き換え可能なセルがあればSmalltalkのオブジェクトもどきな「メッセージを送るもの」を表現できるというのは先ほど書いた通りです。

Masanori Ogino @omasanori

@cametan_001 といったところで「クロージャやCPSは分かったけれどいわゆる巷のOOPとの関係が今ひとつピンとこない」という本題に移りますが、いわゆる巷のOOPはC++以来、抽象データ型や部分型に重点を置いているのでピンとこなくても仕方ないねというのが要点です。

イカ娘 @came_tongue_000

@omasanori ふむ、でも何か繋げたいんでゲソよね。CPSで構築するオブジェクト指向ってどんなんだろ、とか要するにSmalltalk的にはメッセージパッシングは複雑で理論上失敗したわけでゲソが(笑)、そうじゃないOOPってSchemeで実現したらどんなんでゲソかねぇ。

Masanori Ogino @omasanori

@cametan_001 抽象データ型 (ADT) は大雑把に言うと「データ型 = データ + 操作」という考え方で、いわゆる巷のOOPでいう「クラス」はADTの一形態です。部分型は「型Aは型Bに含まれるという関係を表現する」という考え方で、いわゆる巷のOOPでいう「継承」です。

Masanori Ogino @omasanori

@cametan_001 先ほどの「クロージャと書き換え可能なセルによるオブジェクト」はそういった型々した話と直接の関係はありません。もちろん複数の操作を持つオブジェクトを表現することもできますし、型をエンコードしてやり取りする操作を用意すればあれこれすることはできます。

Masanori Ogino @omasanori

@cametan_001 することはできますが、直接の関係はないので、レキシカルクロージャと書き換え可能なセルという素材だけ渡されていわゆる巷のOOPを連想できなくても仕方ないのです。なお、実装主導なOOPLに理論的な基盤を提供する試みは多数存在します。おしまい。

イカ娘 @came_tongue_000

@omasanori 一旦Plannerがどういう言語なのか調べてみればいいかもしれんでゲソねぇ。

Masanori Ogino @omasanori

@cametan_001 なるほど。それをOOPと呼ぶかはともかく（というか呼ばないのですが）アクター的な並行計算モデルはErlangなどさまざまなプログラミング言語に受け継がれたのですが、そういった方向でなく、ということでしょうか。

イカ娘 @came_tongue_000

@omasanori アクター的並行計算モデル採用の言語・・・そうでゲソか、Erlangもそうでゲソか。ふうむ。あるいはSimulaがどんなモンなのか・・・いや、やっぱSchemeの本懐としてはアクター的並行計算モデルに突き進むのが正解かもしれんでゲソ。

Shinji Kono @shinji_kono

@cametan_001 もともと、Hewitt のActor を「これはLispだ!」と言って(並行処理抜きで)実装されたのが Scheme だったり。Smalltalk も Simula から並行実行を抜いたもの。

イカ娘 @came_tongue_000

@shinji_kono うん、だから本当は関数型言語的な関数型言語としてプログラムするより、アクターを使ってプログラムしていくのが本質的にはSchemeっぽい(っつーか元々の目的と合致してる)使い方なのかな、と言う一種妄想でゲソね。

Shinji Kono @shinji_kono

Actor の並行実行も色んな流儀があってさ。Future は米澤先生のABCLから。自分でも Prolog base で一つ作った。

イカ娘 @came_tongue_000

ちなみに、90年代くらいのSchemeの書籍とか見ると、当時のPCとかのパワーが全然ダメで、 「CLが動かせないPCの為に」 Scheme使います、って本の方が圧倒的だったんでゲソね。当時は日本じゃ代用品だったでゲソ。

Masanori Ogino @omasanori

@cametan_001 先ほどの話の補足。いわゆる巷のOOPLの祖先であるSimulaにはコルーチンという機構がありますが、コルーチンと（call/ccよりも制限された形の）継続は等価であることが示されています。SimulaはSmalltalkにも影響を与えています。

Shinji Kono @shinji_kono

OOPな実行理論と言うと、μ計算。並行実行が入ったものだと、π計算。Bisimulation とか散々研究された。でも、実際のシステムに使えるかと言うと、今でもちょっと。モデル検査や、定理証明でも、二桁差がある感じ。でも昔に比べれば近い。

イカ娘 @came_tongue_000

しかし、「関数型言語時代」を迎える前のCLっつーかLispの書き方でScheme書いた日にゃあもう(ry

Shinji Kono @shinji_kono

ほとんどの検証アルゴリズムは指数や多重指数。でも、何に対する紙数かというと変数の数で、プログラムの長さに対しては線形だったりすることが多い。イベントやロックを安易に増やすなってことだが…

Masanori Ogino @omasanori

@cametan_001 今のScheme (IEEE Scheme, R7RS Scheme, etc.) は初期に存在した並行計算用のプリミティブを取っ払っているのですが、また1970年代にタイムスリップするというのもそれはそれで面白い気はしますね。