クロージャとオブジェクト:オブジェクトの定義

オブジェクトの定義...
くちばし突っ込み男です。...
確かに、「同じことが出来る」と言い出したら...
くちばし男です。...
いや、ちょい待った。 -戯...
SHIMADAです。くちばしさんの...
戯さんうまい。Schemerの感覚はそんな感じです。...
えー、ばし男です。...

オブジェクトの定義

＞通りすがりの者ですが、くちばしを突っ込んでみます。 (クロージャとオブジェクト)
まだ用語上に混乱があるように私には感じられます。

closureは、λ算法＋レキシカルスコープ＋無限エクステント、と言って問題ないと思います。(あっでも代入が入るとややこしくなるか、今はパス)。

objectの方ですが、「一つの役割に関連した変数とそれを操作する<<関数>>の組」と言ってしまった時点で特定の実装を仮定してしまっているように思えます。

もともとのOOのアイディアは、独立した内部状態を持つ実体にメッセージを送る、というものだったと思います。それを手続き型言語の実装にフィットするように落し込む際に、「objectにメッセージを送る」＝「objectのメソッドを起動する」というふうにしたのでしょう。で、メソッドというのは特殊な呼び出し方をされる関数だとしたのは、これはもう実装の問題です。

基本に戻って、メッセージパッシングのみでコミュニケーションするobjectがあったとします。objectに何かを頼むのに、メッセージを送ります。

object <- message arguments ...

でも、これなら、クロージャを使って

(closure message arguments ...)

と書いても同じじゃないか、というのがGLSの主張だと理解しています。

[[id:621]] 2002-06-07 09:08:43

くちばし突っ込み男です。

(closure message arguments ...)

の場合、closureの内部でmessageに従ってメソッドディスパッチを行うわけですよね？（誤解してるかな。）
つまりオブジェクトと等価であるためには、メソッドディスパッチの部分を隠蔽できる仕組みを持つ必要があるはずです。
結果として「同じことが出来る」ということが「同じ概念」を示しているわけではないと思うのですが。
いかがですか？

[[id:1299]] 2002-06-07 09:08:43

確かに、「同じことが出来る」と言い出したら

全てはチューリング等価に落ちてしまうので、危険な領域ですね。気を付けねば。

で、メソッドディスパッチが隠蔽されていなければならない、あるいは言語組み込みでなければならない、とするなら、確かに上の例はclosureでobjectをエミュレートしているだけとも言えます。

ただ、ほんとにそうでなければならないのでしょうか。

(define-class foo
(val)
(method (get-val) val)
(method (set-val v) (set! v val)))

を

(define foo
(lambda (val)
(lambda (msg . args)
(cond ((eq? msg 'get-val) (apply args (lambda () val)))
((eq? msg 'set-val) (apply args (lambda (v) (set! v val))))
))))

とするマクロは非常に簡単ですし、前者は後者の糖衣構文に過ぎないように思えます。
後者が実際に実行される時に本当にcondを使ってメソッド名を線形探索するかどうかは問題ではないと思います。このパターンが頻発するなら、処理系作成者は上記のパターンを認識してそこだけ組み込みインストラクションを出すようにするかもしれません。そうだとしても、外から観察している限りはその違いは分かりません。外から違いが分からないのなら、区別する必要もなさそうに思えます。

[[id:1298]] 2002-06-07 09:08:43

くちばし男です。

構文糖を作ってまで表現しようとしたモノ（あるいは概念）は一体なんでしょうか？
実装が簡単であるか否か、それが組み込みのプリミティブなのかマクロに
よる構文糖か、に関わらず共通した表現したい「何か」があると思うのですが。

(closure message arguments ...)

の例に戻ると、messageとargumentは共にclosureの引数のハズですがもはや意味的には全く違った「別のもの」になっていると思います。
ところでclosureそのものはmessageとargumentを区別してはいませんよね。
「closureでobjectをエミュレート」することによって、使用者が意味の差を見い出しているに過ぎないはずです。

で、使用者が構文糖を通してそこに見ている概念とは「メッセージ」に応答する自律した「オブジェクト」であって、この段階ではclosureはオブジェクトを実装するための一つの手段でしかありません。

「closureがあるからわざわざオブジェクトのパッケージを作るほどのことではない。」という主張なら理解できますが。

[[id:1297]] 2002-06-07 09:08:43

いや、ちょい待った。 -戯

closure、というかソレを持ったschemeでは、構文が無い(といういいかたで
良いんでしたよね)ので、どんなラッパーをscheme上で書こうが、
違和感はない、つまり「違和感の度合は変化せず常に一定である」、
ということなんじゃないでしょうか?(^^;;;;;;;

ま、俺がbasicからCに移行したときに、print(に相当するもの)が
文じゃなくライブラリ呼びだしでしかない、というのは、
結構新鮮だったなあ、という記憶が有りますが、あれですね。
ライブラリだったら違和感が有るのか?というとそうじゃなく、
ライブラリだってなんだって違和感がそんなに「増え」ない、
というような文法(?)になっていれば、嫌な気分にはならない。

[[id:1301]] 2002-06-07 09:08:43

SHIMADAです。くちばしさんの

＞ messageとargumentは共にclosureの引数のハズですが
＞もはや意味的には全く違った「別のもの」になっていると思います。
には、オブジェクトに送信するメッセージとはメソッド指定とそれに続くメソッドへの引数列だ、という前提を感じます。
しかしそれとは異なる様式でメッセージを送信する文法もあります。引数の数や型でディスパッチが変わるC++やJavaは引数の並べ方もメソッド指定の一部だと言えなくもないですし、Smalltalkのキーワードメッセージは全く異質です。

-オフトピ：後置キーワードメッセージ (笑)

schemeのクロージャでキーワードメッセージのような仕掛けも作れますし、
(object keyword1 argument1 keyword2 argument2 keyword3 argument3...)
結局
(object message argument...)
ではなく、もっと大きくとらえて
(object message...)
と考えるべきなんでしょう。

-MultipleDispatchまで視野に入れると結局はMessageSendingって結局は「状態屋と処理屋のコラボレーション」の一言で説明できるなぁと思えたりします。で、ロックバンドなのかビッグバンドなのかオーケストラなのか、という組み方の違いが有るだけというか。

[[id:658]] 2002-06-07 09:09:37

戯さんうまい。Schemerの感覚はそんな感じです。

だから確かに、「頭の中でメッセージと引数が分かれてるんだから、言語上も反映されてないとなんだかなあ」と感じる人にとっては、Schemeでやってるようなことは単なる実装手段にすぎない。どっちが本質かっていう議論は、この感覚の違いを抜きにしていたら平行線になってしまいますね。

OO的にみて、Schemeのアプローチがどんなふうに違和感があるのか (そして逆にどんなアプローチが自然なのか)、というのを知るのはSchemerとして非常に有用です。「グラフ計算ソフト」に期待してます。

[[id:659]] 2002-06-17 23:25:32

えー、ばし男です。

＞戯さん
自己拡張性のある言語はこのあたりがキレイで良いですね。
インクリメンタルに概念を取り込んでいけるというか、なんというか。
ところで「六本松」期待してます。（というか萌え）

＞SHIMADAさん
勉強になります。
＞結局
＞(object message argument...)
＞ではなく、もっと大きくとらえて
＞(object message...)
＞と考えるべきなんでしょう。
なるほどー。
でも、あえて反論してみると、やはりclosure内部でmessageに対するディスパッチの部分が隠蔽されているわけではないですよね？
(closure argument....)
と
(object message...)
は表面上の表記が同じなだけで。

closureとobject
argumentとmessage

は意味的に変質していると思うのです。
Cでも構造体に関数ポインタを突っ込んで「オブジェクト指向」することができますよね。
structがobjectを「エミュレート」するわけですが、ここで「オブジェクトとはつまり構造体だ」
と主張したら恐いお兄さんたちにボコられてしまう（？）のではないかと‥‥。
ま、Cで「オブジェクト指向」してもちっともエレガントじゃないので、全く比較にならないとは思いますが。

＞「頭の中でメッセージと引数が分かれてるんだから、言語上も反映されてないとなんだかなあ」と感じる人にとっては、Schemeでやってるようなことは単なる実装手段にすぎない。どっちが本質かっていう議論は、この感覚の違いを抜きにしていたら平行線になってしまいますね。

言語上反映されているかどうか、が問題なのではなく、明らかに別の「概念」として存在している、という所に力点があるのです。
どっちが本質か？という議論をやってるつもりはあまりないです。

あと、objectに対置すべき概念はclosureではなく、Generic Functionではないだらうか？（誤解？）
-object=「データ＋プログラム」という点に着目すれば、object≒closure
-object=「多様性」という点に着目すれば、object≒Generic Function≒型総称？

[[id:1300]] 2002-06-17 23:25:32

top recent

HashedWiki version 3 beta
SHIMADA Keiki