2494. Re. 2493 Re. 2492 Re. 2491 Re. 249...
亀田馬志 (Nov 23, 2009)
>>LOLOLさん
>そうですね。Rubyは純粋なOOPとして設計されていますね。
>純粋なのはいいことだ。\(^O^)/
これ、ちょっと以降で考えてみましょう。
>私は、Gaucheって、ちょっとシンタックスの違うscheme方言なのかなくらいに思っていたんで、わざわざmzscheme
でなくGaucheを使う意味がどこにあるのかなくらいにいままで思っていたんですよ。
いや、シンタックス自体はほぼ同じなんです。
むしろ、今では古典的なR5RS処理系になっちゃったような感じです。
(他にはGuile、SigSchemeなんかがありますが、PLTなんかの「ユーザーベースが大きい」処理系は徐々にR6RSに
移行していってます)
Gaucheの場合は「実用主義でのScheme」を狙ってるんです。特にWebアプリを書く場合、おそらくデフォルトで
は最強の能力を発揮するScheme処理系でしょう。
ただ、「Scheme初心者が使う処理系」としては特徴がありすぎるんですよね。
Gaucheの場合は「実用主義」の為、例えばデフォルトでSRFIのいくつかのライブラリが使えるようになっていて
、他のScheme処理系だと「互換性が無い」的な勘違いを生み出す要因を作っちゃってるんです。
つまり、ある程度Scheme知らないと、使うのがアブないんです(笑)。Web検索すると「Gaucheには××があるけど
他には無い」的な勘違い書いてる例があとを断たなくて(笑)。
もう一つは、川合史朗さん自身が実はバリバリのCLerでもあるんで、Common Lispの機能なんかもCLOS見れば分
かりますが「持ってきちゃってる」んですね。CL知ってる人はいいんですが、そうじゃないと混乱の元でしょう。
これには、例えばCLでの悪名高い出力関数、formatなんかが挙げられます。
(ちなみに、SRFI48にもformatが定義されていますが、Gaucheのそれは遥にCLに近いです。)
オーム社の「プログラミングGauche」なんかもその辺、Gauche依存バリバリで書かれているんで、そう言う辺り
がかなり注意が必要です。「分かってる人」には良いんですが、そうじゃないと混乱しますね。かつ、どう読んで
も「Perlプログラマ向け」に書かれてるんじゃないか?と思う箇所もあり、かなり対象読者が曖昧なんです。
基本的には「CL機能由来の機能」はCLで学ぶべきだろう、と思います。CLやってみて、「Lisp-2の構造的な汚さ
」が嫌で、その辺でScheme使いたい、と言う場合、Gaucheは強力な武器になるんじゃないのかな、って思います。
>CLOSの構造をまねたとあるんで、そうなんでしょうね。
さて、では最初のトピックから。
何故Schemeのオブジェクトではクラスがトップからインスタンス形成でヒエラルキーが構成されてないのか?
R5RSでは基本的に次のように定義されています。
>どのオブジェクトも下記の述語を二つ以上満たすことはない。
>boolean? pair?
>symbol? number?
>char? string?
>vector? port?
>procedure?
そもそもある種R5RSは仕様が曖昧なんですけど、字面見る限り、「この条件を"まずは"満たす」前提だと、果た
してclass-ofってのが何なのか、って話になるでしょうね。これらの定義以前に根底的に「どこかのクラスに属し
てる」って話になってしまう。
となると、上の定義自体がある意味曖昧になり兼ねません。そう言った理由で必ずしも「純粋である」必要性が
無いんです。言語構造的なパラダイムが違うんですね。
まあ、その辺も了承済みでGaucheは「実装方針として」純粋OOPを「選んだ」って考えた方が良いと思います。
次の問題として。ではSchemeはどうしてOOPを積極的に取り込まないのでしょう?
それは、例えばCLOSとか見れば分かりますし、Javaの経験がおありなら分かるでしょうが、
・原則、クラスベースのオブジェクト指向では、インスタンスのスロットを「破壊的に書き換える」操作が前提
だから
と言うのがポイントになってるわけです。
反面、Scheme等の関数型言語の「プログラミング指南」では、スタイルとして、
・データを「破壊的に」書き換えるのを良しとしない
わけです。分かりますかね?平たく言うと、基本的には、「関数型プログラミング」のスタイルと「オブジェク
ト指向プログラミング」って「相容れない」んですよ。スタイルの問題として。
Common Lispみたいな「何でもアリ」が前提じゃないと、オブジェクト指向ってのは「導入出来ない」んです。
(ちなみに、はじめて「オブジェクト指向言語」として公式に制定されたのは実はCommon Lispで、C++よりも早
いのです)
これ、Erlangの設計者の一人であるJoe Armstrongも力説してました。
Why OO Sucks:
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
そして、これがErlangが何故一般的な意味でのOOPじゃないのか、その理由です。Joe Armstrongは全くOOPを信
用していない。
この辺OCamlに対してもある種批判があるでしょうね。Haskellなんかの「純粋関数型言語」だととにかくデータ
を「破壊的に書き換える」事を良しとしていません(※)。一方、関数型言語の中で、コンパイルしたプログラムの
実行スピード最速を誇る(話によればCと遜色のないマシンコードを吐き出すと言われる)OCamlは破壊的操作を許し
ています。そしてそれ故にオブジェクト指向を「積極的に」取り込んでいます。ただ、純粋な「関数型言語ファン
」だとOCamlを「良し」とはしないでしょうね(当然CLに対してもそうなわけで、それ故に一種反目があるんですが)
。
Schemeは定義上「破壊的操作を許す」んで、「純粋ではない」関数型言語ですが、同時に何故「純粋な」オブジ
ェクト指向言語に成りたがらないのか、と言うのもこの辺が鍵なんです。また「純粋な」オブジェクト指向言語に
「なる」ってのもプログラミングスタイルのトレードオフの関係上、実際はあまり薦められないんです。
この辺の議論も、実際SICPの第3章辺りで議論されていますね。
ここで最初に扱われているのは、平たく言うと「オブジェクト指向」のSchemeでの実装で、「もうひとつのScheme
入門」での
3. 代入と内部状態:
http://www.shido.info/lisp/scheme_asg.html
と関連がある議題です。
かつ、SICPでは、3.1.3でこの形式の「プログラミング技法」に批判的な立場を取っています。
(ただ、この辺、OOP信者から「SICPは意図的に読者を"OOPはダメ、関数型はサイコー!"と言う所へ誘導しようと
してる」と批判を受けてる事も指摘しておきます。)
Gaucheはその辺全て「分かっていて」、敢えてCLOS的なオブジェクト指向をベースとして取り込もうとしたんで
しょうね。
※:実際は、Haskellにもオブジェクト指向を取り込もうとしているHaskell++やO'Haskellと言う変種が存在して
はいるようです。が、あまり知名度が高くない辺り、純粋関数型言語ファンであるHaskellユーザーにそれ程魅力
的な機能とは映らないのでしょう。
- 元ねた:
- 2493 Re. 2492 Re. 2491 Re. 2490 Re. 248...
- フォローアップ: