単一責務原則（SRP）から始まるFPとOOP

uehaj @uehaj

.@kmizu 今回のやりとりを通じて自分なりに得た答えは、OOPおよびFPは、それぞれの基本的な定義上の意味では対立しない、です。あるいは対立しないような形のプログラミング・運用方法論を、言語設計者が仮説し、考案し、定義し、実証していくことができる。

uehaj @uehaj

.@kmizu しかし、逆に言えば、FPではなく個々のFPLにおいて、FPの基本概念をそれぞれに発展させた、FPの実装とでも言うべき運用方法論は、OOPと対立する可能性が十分にあり得る。それらの対立項が、それぞれに非常に興味深いと思っています。

uehaj @uehaj

.@kmizu 例えばクラスではなく、関数をプログラムの構成基礎構成要素と位置付ける、などです。

uehaj @uehaj

.@kmizu あるいはFPの発展として「マップやリストの基本を多用し高階関数で処理することで名前のついたクラスを導入しない」という方針もありえます。これは別にOOPに反しませんが一時話題になった「OOP養成ギブス」一種の「OOPの発展的適用体系」で求められるスタイルには反します

uehaj @uehaj

.@kmizu 実際その種の対立を、Scalaの中でも見つけることができる気がしていて、型クラスによってthisを通じないメソッドのadhoc多相性をもって何かを実現した体系Scalazは、ScalaコアのFP+OOPとは「別体系のFP」でもあるように思われます。

uehaj @uehaj

.@kmizu 他に、FP遅延評価こそが関数型のキモであり、副作用は持たない、じゃなくて持てない、的な立場も、融合はしにくい方です。OOPに、というだけじゃなくいろいろな意味で。

uehaj @uehaj

.@kmizu 以上です長文失礼しました。ブログにした方が良い気は多々したのですがせっかくですので。またよろしくお願いします。

uehaj @uehaj

型クラスは継承を代替できるか?A:「存在量化型」拡張を使えば。OO abstract class declaration declares the equivalent of 3 things in Haskell: a class… http://t.co/MiHLlSe9kq

uehaj @uehaj

OOのclassは、常にexistential type化を伴なっている。しかしできることは共通部分でしかない。Haskellでは別々にあつかえる。だから一般的で強力なのだとね。まあそうかもしれんが難しわhttp://t.co/VOkCPu5mcE

uehaj @uehaj

逆に言うと、OOP classは難しいことを簡単にやる力でもあるということだ。自由度は制約されるわけだが、それは我慢我慢。個人的には、haskellベースでclassを表現する自然なSyntax Sugerがあれば良いと思う。lens?(白目

uehaj @uehaj

.@kmizu ふと思い出したように補足ですが「インスタンスメソッドが必要悪になるのでは」と言ったのは型クラスがScalaのFP位置付けのベースであるような状況かと思ってたからです。

uehaj @uehaj

.@kmizu implicit変換で実現するScalaの型クラス機能において多相的に提供される関数はいわゆるインスタンスメソッドではないという理解です。正確じゃないな…型クラスがターゲットとする多相型変数をthisとするインスタンスメソッドではない、というか

kmizu @kmizu

@uehaj 丁寧にありがとうございます。仰るとおり、FPとOOPは基本的な技法として対立しないものの、個々のFPLで多用される技法と対立する可能性はあると思います。最近しばしば発生しているHaskeller VS. Scalaistのframe warもその典型だと思います。

kmizu @kmizu

@uehaj ちなみに、遅延評価こそが関数型のキモであるというのは、初期の関数型プログラミングにおいて指示された考え方であり、実際HaskellやCleanではそう（デフォルトの評価戦略がnon-strict)なっていますが、現在はそのような考えはかなり後退しています（続）

kmizu @kmizu

@uehaj Haskellの設計者の一人であるSimon Peyton Jonesは http://t.co/u2x65idU1z の中でHaskellの設計に関する反省として、「The next Haskell will be strict, but still pure」

kmizu @kmizu

@uehaj と記述しています。実際、現在のHaskellコミュニティで遅延評価こそがキモであるという考え方はかなり後退しているようです。ちなみに、遅延評価の関数型プログラミングの重要性は、「何故関数プログラミングは重要か」http://t.co/RQys3cW4uf

kmizu @kmizu

@uehaj において強く主張されましたが、結局、現在それほど強い勢力を誇っているわけではないということです。

kmizu @kmizu

@uehaj こちらは別のリプライとして。まず、型クラスがScalaのFPの位置づけのベースにある、というのは歴史的にみても事実上も間違いです。型クラスはOderskyによってScala 2.0で”Poor Man’s Type Classes'として取り込まれましたが

kmizu @kmizu

@uehaj それはあくまで研究向けの発表でのことであり、Scala 2.9以降になるまで、長らくこのことは非研究者にはほとんど知られていませんでした。

kmizu @kmizu

@uehaj ちなみに、Oderskyのスライド『Poor Man’s Type Classes』は http://t.co/CPqx2gmH4i (PDF注意）からみることができます。Oderskyが研究向けと一般向けで注意深く説明を分けていることがよくわかりますw

uehaj @uehaj

.@kmizu 興味深いです。Haskellでは入出力ライブラリが遅延IOからIteratee/enumeratorに移行しつつあるようですが、後者はIOと併用する同期的なものです。というのもその例でしょうか。

kmizu @kmizu

@uehaj Scalaのimplicitが事実上型クラスであるというのはどちらかというとScalaコミュニティによって「発見」されてしまったという部分が大きく、Oderskyはあまりこういう”Scared”なtermを積極的にプッシュしたくなかったのではないかと推測します。

kmizu @kmizu

@uehaj これは微妙なところなのですが、Scalaでimplicit引数を持つメソッドも、動的ディスパッチの対象になるという点でれっきとした「インスタンスメソッド」であると言えるかと思います。Scalaのコレクションライブラリは、

kmizu @kmizu

@uehaj Scalaのimplicit引数をもったメソッドがインスタンスメソッド「でもある」事実を利用しています。

uehaj @uehaj

.@kmizu デフォルト非正格評価/call by needsについてはとても良い面もあるがたいへんでもあるという認識です。thunkの動作が手足のように見えるようになれば、たぶん全然違くて、そこまで到達できれば良いのですが。確実に言えるのは、当面は普及はしないだろうと