scalazにおけるimplicit parameterの命名規則

抑圧されているんだ @writeboostguy

Scala質問: def f[A](A: Monoid[A])における, 2番目のAは型を表してるの？例えばIntとか

抑圧されているんだ @writeboostguy

A: Monoid[A] って型が再帰してるように見えるのだが, どういう記法なんだ？

抑圧されているんだ @writeboostguy

a: Monoid[A]と書くものではないの？紛らわしいので.

抑圧されているんだ @writeboostguy

なんでこんな紛らわしい書き方するのだと小一時間悩んだ. A: Monoid[A] の1

抑圧されているんだ @writeboostguy

つ目のAと, 2つ目のAは関係がない・・・2つ目のがIntならば, 1つ目はMonoid[Int]のインスタンスですよと言ってるだけか

がくぞ @gakuzzzz

@writeboostguy 2番目のAはただの引数名ですね。

抑圧されているんだ @writeboostguy

@gakuzzzz Thanks. やっぱそうですよね. 紛らわしいのでmaとか書けばいいのにーと思いました.

がくぞ @gakuzzzz

@writeboostguy 全く同意ですね。この辺 Scalaz でもFPinScalaのような命名規則なんですが、github.com/scalaz/scalaz/… 個人的にはこれは Haskell 文化圏から引き継いだ悪しき風習な気がしています。単純に読み辛い……。

抑圧されているんだ @writeboostguy

@gakuzzzz 型が再帰してるように見えて混乱します. Scalaって型を引数にとれるのか？とも思いました. 文化なので改善は無理そうですね. 慣れ従うしかりません.

がくぞ @gakuzzzz

@writeboostguy 慣れは多分にありそうですねー。ただまぁScalaコミュニティ全体がそういう文化という訳でもなさそうなので、この辺はよりよい提案を出して行けば受け入れられる余地はあるように思ってます

Kenji Yoshida @xuwei_k

@gakuzzzz @writeboostguy Haskellではそもそも型クラスのインスタンスの実体はScalaみたいなオブジェクトとして存在しないので、(名前つける行為自体を避けるため)型クラスのインスタンスは型と同じ名前にするというのはある意味Scalaz独自の慣習ですね

がくぞ @gakuzzzz

@xuwei_k @writeboostguy あーそれはそうなんですけど、例えば liftM :: (Monad m) => (a -> b) -> m a -> m b liftM f m = m >>= (\x -> return (f x))

がくぞ @gakuzzzz

@xuwei_k @writeboostguy の m a 型の変数にmとつける、とか個人的にHaskellの読み辛さはこういう所か来てるように感じてて、Scalazのそのルールはそれを引き継いでる様に感じてます。

Kenji Yoshida @xuwei_k

@gakuzzzz @writeboostguy 名前付け避けれる機械的な命名規則ならなんでも良かったんでしょうけど(順番にev1とかev2とか)scalaz7のプロトタイプ作った人がその規則をドキュメントに書いて(別にみんなこだわりないので)それに従うようになって今に至ってます

Kenji Yoshida @xuwei_k

@gakuzzzz @writeboostguy あ、はい。もちろん短い機械的なわざと意味のない名前付ける文化の大枠自体は、主にHaskellの影響だとは思います

がくぞ @gakuzzzz

@xuwei_k @writeboostguy 本当に使わないのであればContext Boundで済むので、名付けを避けるのがバッドノウハウな気がするんですよねー。コード中で明示的に使うんだから識別しやすい名前をつけて欲しい感あります。ってここでいうより提案しろって話ですがｗ

がくぞ @gakuzzzz

熟練Haskellerは型を扱うコードと値を扱うコードを無意識レベルで分けてるので型名と同じ変数名とかあっても混乱しないんだろうなー という気がしてる。まーScalaもコンパニオンobjectとか境界があやしいやつあるけど

Kenji Yoshida @xuwei_k

@gakuzzzz 型さえ分かれば型クラスのインスタンスが一意に定まるので、その名前なんて考えたくないというか考えるべきではないという思想のはずなので、まぁ がくぞーさんとscalazの考えは相容れないので、どうしようもないという結論(?)

がくぞ @gakuzzzz

@xuwei_k 世の中厳しい

がくぞ @gakuzzzz

implicitly がもうチョイ楽に書ければそっちの方がわかりやすいのではないか感ある

がくぞ @gakuzzzz

つっても僕も適当に ev1 とかつけてますてへぺろ

Kenji Yoshida @xuwei_k

@gakuzzzz あー、そのためにscalazはコンパニオンにapplyあって、ほぼ全てをcontext boundとそれで済ませることは可能なのでそれでもいいんです。が、そのあたりの規約は特になくて、両方ごぎゃ混ぜなのは整理してもいい、が誰もその整理に興味ないので混ざったまま

がくぞ @gakuzzzz

@xuwei_k そうそう、Scalazのあのコンパニオンのapplyはいいしくみだなーと思ってます。オーバーヘッドとか気になっちゃってそっちに統一すべしみたいな提案ははたして良いのか？と悩んでみたり

Kenji Yoshida @xuwei_k

@gakuzzzz 仮にそこを整理するpull reqが来たとして、他の人の反対がなければmergeして統一してもいいけど、結局自分もその整理どうでもいいので(?)、オーバーヘッドもそうだし、gitの履歴が無駄に増えるというデメリットもあるので放置してる感じですね

Toshiyuki Takahashi @tototoshi

@gakuzzzz @xuwei_k がくぞーさんzが4つもついてるのに...