型クラスのインスタンスはグローバルで1つであるべきか

ると @cocoa_ruto

@kmizu それで実用上問題ないというのか結論なのだったらそれはそれでいいんだけど、結局界隈としては「coherenceなんて要らなかったんだ」ということになってるの?

kmizu @kmizu

@xuwei_k Wadlerの型クラス論文ではType Classesの要件として、そもそもそんなこと言ってないのでekmettせんせが勝手に言ってるだけでは…

kmizu @kmizu

@cocoa_ruto いやまあ、界隈がどこの界隈を指すかに大きく依存する気はするけど…

kmizu @kmizu

@cocoa_ruto あと、自分も別にcoherenceを保つ必要がないとは言ってなくて、library designer/author の契約の元で保たれていれば良いという立場で、coherenceなどどうでもよいというわけではないので念のため。

ると @cocoa_ruto

@kmizu その辺前にRoyの設計の時に話題になって、そのときは結論出てなくて、今どうなってるのか気になったので。そのときはMcKennaさんはScalaのmisfeatureとまで言っていて、私はScalaの肩を持っていた。 github.com/puffnfresh/roy…

Kenji Yoshida @xuwei_k

@kmizu 原典の言葉の定義をもとに議論するのも大事ですけど、実際その論文出てだいぶ経過してるわけですし、実際の型クラスの使われ方や言語毎の差異を考慮して議論しないことには、あまり有益な議論にならないような。 より適切な定義があるなら言葉の定義多少変わるのもありえる？でしょうし

Kenji Yoshida @xuwei_k

とても雑にいうと twitter.com/xuwei_k/status… たぶんScalaっぽい方式とHaskellっぽい方式と、メリットデメリットがそれぞれあるわけで、そのあたりを誰かまとめてくれ、とかそういう (別に個人的に唯一の"型クラス"の言葉の厳密な定義を決めたいわけじゃない)

Kenji Yoshida @xuwei_k

twitter.com/xuwei_k/status… 曖昧な記憶で結論だけ言うと、Scala(がimportで制御できたりimplicitを明示的に渡せてしまうことなどに？)だいぶ否定的だったはず(よって型クラスではない、と言ってる？)けど、誰かもっとうまくまとめておいてくれ

2015-09-24 19:58:53

kmizu @kmizu

@xuwei_k ちょっと言葉が過ぎたかもしれないのですが、今までさんざん非アカデミック勢が元の言葉の意味を好き勝手に変えるのを見て（古くはクロージャの意味とか）きているので、その辺でついかっとなった面はあります。

kmizu @kmizu

@xuwei_k たぶん、私は型クラス「ではない」のような強い言明をするなら型クラスとは「～でなければならない」という形での再定義が最低限必要だと思ってて、そういう言明なしにカジュアルに用語を再定義するのがあまり好きではないのだと思います。

Kenji Yoshida @xuwei_k

@kmizu なるほど。まぁ別に個人的には言葉の定義変える部分にこだわりそんなにないけど、Scalaのやつが型クラスじゃないということになったら「型クラスっぽいけど型クラスの最低要件を満たさない何か」を表す別の言葉が必要になって、それはそれで面倒ですね(?)

kmizu @kmizu

@kmizu だから、今でも「クロージャ＝コードブロックをオブジェクト化したもの」といった解説には強い嫌悪を覚えるのだと思う。会話するときに常に原典主義を用いるわけじゃないけど、専門であるCS分野（の一部）に関しては自分は割かし原典主義だと思う。

kmizu @kmizu

@cocoa_ruto なるほど。taku0が .@cocoa_ruto 君のか。

kmizu @kmizu

@cocoa_ruto ところで、ちょっと見方を帰ると、Scalaのimplicitというのは暗黙のオブジェクト渡しにすぎないのだから、普通に引数を渡すときと同じようにLSPを侵さないべきだということができるので、型クラスに契約を書き、そのインスタンスは契約を守るようにする

kmizu @kmizu

@cocoa_ruto というのはOOP的考え方では極めて普通なように思うし、これは型クラス（のデフォルト実装）とそのインスタンスの実装変更にも適用できる原則だと思う。

ると @cocoa_ruto

@kmizu 実用上は問題ない気もするけど、複雑なデータ構造と、(implicitなパラメーターをとるimplicit defで辞書が決まるような)複雑なインスタンスを組み合わせたときに、元の動機である複数の辞書を使い分けるというのがうまく行くのかイマイチ自信がない。

ると @cocoa_ruto

@kmizu かといっていちいちnewtypeするのも現実的でない気がするし、よくわからない。

Kenji Yoshida @xuwei_k

Haskellのnewtypeのように本当ゼロコストで安全に新しい型作れるか否か？も、型クラスのインスタンスをグローバルにするかどうか(そうした時の利便性)に関わるだろうしなぁ

kmizu @kmizu

@cocoa_ruto coherenceの問題、考え直してみたんだが、こういう理解で良い？ gist.github.com/kmizu/a93baa00…

kmizu @kmizu

@cocoa_ruto まあ、考えた結果、実用上は問題ないだろうという結果になったのだけど。型システムでガードするにはどうすればいいかというのは実用性はおいといて面白いかもと思った。

ると @cocoa_ruto

@kmizu 問題としてはそうなんだけど、LSPについてはよくわからない。LSPって「親クラスのインスタンスで成り立つ性質は子でも成り立つ必要がある」であってるよね。それで、ここでは親と子はそれぞれなにで、成り立つ性質ってなに?

kmizu @kmizu

@cocoa_ruto この場合はLSP言う必要なかった。単にメソッドの事前条件を満たさない(setAとsetBの要素は共に探索木の中で昇順か共に降順かのどちらかでソートされたものでなければなければならない&&ordはsetAとsetBが昇順ならば昇順、降順ならば降順)で十分かな

kmizu @kmizu

@cocoa_ruto さらに考えてみたんだが、Haskellの型クラスであっても、TreeSet[A]の内部構造が露出していたら順序デタラメな探索木を手作業で作れてしまうので、その上でのcoherenceを考えても、結局「実用上の」とつけなければいけなくて安全じゃない気がする

ると @cocoa_ruto

@kmizu 一般にはOrdのインスタンスは無数にあるのでunionの事前条件としては単に昇順・降順ではなく、「setAとsetBの構築に使った順序と、このメソッドに渡される順序は全て一致する必要がある」であり、これはcoherenceを守ろうと言っているにすぎないのでは。

ると @cocoa_ruto

@kmizu Haskellでは(分割コンパイルの問題を無視すれば)整合性を保証できるようなTreeSetの定義を書けるのに対して、Scalaでは保証できるようなTreeSetを書けないので異なるのでは。

kmizu @kmizu

@cocoa_ruto Haskellのdata宣言で宣言したADTだと任意の木構造が許されてしまうのでは？