型クラスに関するここ数日の議論

ruichi @ruicc

型クラス的なものが諸々の言語に入るならあとHaskellで難しいやつは遅延評価くらいですね（適当）

Cubbit @cubbit2

「型クラスはオブジェクト指向におけるインターフェイスみたいなもの」って良く言いますが、「みたいなもの」って言っているようにもちろん正確ではないものの、方便としてはまったく悪くないと思います。コードを書きながら学んでいる分には、特に混乱を招くということもないと思います

Cubbit @cubbit2

ただ、コードを書かずにその辺のブログやウィキペディアの記述をレポートにまとめるだけのような学び方だと、まったく明後日の誤解にたどり着きそうです。型クラスは『インターフェイス』よりも強力なのですが、『インターフェイス』があれば型クラスは要らないなどと考えちゃう人もいるかもです

Cubbit @cubbit2

型クラスが何なのか知りたい人は、PureScriptのコンパイル後に出力されたJavaScriptコードを覗いてみるのもいいと思います。拍子抜けするほど簡単です

Soutaro Matsumoto @soutaro

僕の場合、型クラスを理解したと思えたのはAPLASのトークを聞いていた瞬間だった。仮説としては「本当に良くわかっている人の話を聞けば理解できる」と「しつこく考え続けていればいつかは理解できる」の二つがあって、まーどっちにしても救いがあるような無いようななんとも言えない感じ。

Soutaro Matsumoto @soutaro

OOPに例えれば理解できるかというと、悲観的かな。僕は、「型クラスを理解した人は、インタフェースとの類似性を理解できる」という逆方向の関連しかない気がする。

seraphr @seraphr

型クラス 理解してしまえば、本当に簡単で便利で素晴らしいものなんだけど、理解するまでは結構かかった覚えがある。 しかし、理解したときのことは覚えていない… 気づいたら理解してたんだよなぁ…

hatebutech @hatebutech

型クラスをOrderingを用いて説明してみる - kmizuの日記 kmizu.hatenablog.com/entry/2017/05/…

Kota Mizushima (on a diet) @kmizu

@soutaro OOPにたとえると理解できるかは自分も疑問ですが、ただ、OOP言語の要素で的確に型クラスをエンコードできる（型から辞書を引っ張ってくる部分は、新しく理解が必要ですが）のも確かであり、 ( lampwww.epfl.ch/~odersky/talks… の p.14辺り)

Kota Mizushima (on a diet) @kmizu

@soutaro OOP言語を使った直接的なエンコーディングを理解することで、型クラス自体も理解しやすくなると思っていて、その意味ではOOPの要素の援用も利点はあると思います（説明の仕方によりますが）

Kota Mizushima (on a diet) @kmizu

昨日と違った視点で、型クラスとインタフェースを直接比較することの害を考えてみると、Scalaにおけるエンコーディングみればわかりますけど、対応関係をつけるのにはインタフェースは要らなくて、（多重継承可能な）クラスがあれば十分なのですよね

h_sakurai @h_sakurai

アルゴリズムW の実装は、アルゴリズミックな推論規則を作ることで劇的に簡単になり、Prologで実装すればわずか数行で実装できるので、型クラスもアルゴリズミックな推論規則があれば、おそらくわずか数行、数十行でかけるはずだと思うんだなぁ。

INA Lintaro @oarat

型クラスどういうふうに盛り上がってるのかよくわかってないけど、個人的にはECOOP 2009でSimon Peyton Jonesのtalkを聞いたときに、vtableの静的バージョンとおもうとしっくりくるなぁ、とおもったのでした。

κeen @blackenedgold

@kmizu コレクションの要素がNumericを実装していればsum自体は実装できますね。 複数のNumericを使い分けたいというのであれば「文脈によって同じ型に対する型クラスのインスタンスを使い分けたい場面」に相当するので私も型クラスでないとできないと思います。

κeen @blackenedgold

@kmizu 「「定義を」分離できるのが型クラスの一番の利点」と言っているのでその点は私はインターフェースでは難しいと思ってます。

革世同・革エヴェ派 @shiro_i_hito

型クラスって型のクラスじゃん。そんだけじゃん。

Kota Mizushima (on a diet) @kmizu

@blackenedgold これは、特定の要素型Tがあったとして、実際にT型のオブジェクトが存在しなくても、型クラスが使える、という話ですが、この点についても、インタフェースを実装するという場合、困難というか無理な話になるのではないでしょうか。

NaOHaq(苛性ソーダ) @NaOHaq

型クラスに関する議論、誰かあとでまとめといて欲しい(他人頼み())

Kota Mizushima (on a diet) @kmizu

@blackenedgold ただ、型クラスだったら、オブジェクトが存在しない場合に特定の動作をするという側面も、「定義の分離」も単一の仕組みで実現可能のに対して、T.zeroみたいな、クラスメソッドを型からひっぱる仕組みだと片方の要求だけ満たすのが弱い部分かなと思いました。

h_sakurai @h_sakurai

型クラスの実装の難しさとC++のような言語のクラス実装の難しさは似ているんだよなっと。

Kota Mizushima (on a diet) @kmizu

@h_sakurai 型クラスに関する推論は、たぶん主に二つあって、一つは型注釈無しのプログラムから型クラスの制約を含む型推論をするという部分、もうひとつは、型から対応する辞書をひっぱってくる部分、があると思うのですが、主に後者の話されてますか？

Kota Mizushima (on a diet) @kmizu

@h_sakurai 型推論がない、あるいは弱い言語での型クラスは、前者があまりなさそうなので、後者の話かとは思っていますが。

h_sakurai @h_sakurai

@kmizu 型推論しつつ、変換を両方同時にできるようなので、それを簡潔なコードで示したいんですね。推論してから変換はより複雑なようなので。というか、型クラスなしのオーバーロードもわからないし、型クラスやアドホック多相が全般的に簡単な実装例が少ないと思います。

Kota Mizushima (on a diet) @kmizu

@h_sakurai なるほど。型クラスなしのただのオーバーロードは（サブタイプなければ）とても簡単です。名前 -> [関数のシグニチャ] みたいなMapをもっておいて、シグニチャリストのどれかにマッチするか判定すればいいだけなので。

Criphy @criphy_sys

@ababupdownba Rubyの時はオープンクラスで後付けでメソッド追加簡単にできてたけどそれは避けるべき行為だと認識してたんですが型クラスとかでやってることってそれとあまり変わらないなと思って。後者は自分でも気にしてなかったので自分の考えが矛盾したなと。濫用はすべきではないと思いますが。