Scala の CanBuildFrom などについて

kmizu @kmizu

ブログ更新。 Stringを要素に持つ任意のコレクションにgrepを適用できるようにする - あるいはScalaの暗黒面について http://bit.ly/l3zFoL #scala

Kenji Yoshida @xuwei_k

ぐぬぬ、勉強になるな(´・ω・｀)つまり自分はCanBuildFromをまだ完全に理解できてない的な… RT Stringを要素に持つ任意のコレクションにgrepを適用できるようにする - あるいはScalaの暗黒面について http://t.co/FvweOQC #scala

kmizu @kmizu

今日のTODO: Scalaの CanBuildFrom について、 #scalajp_site のコラムに書く。 http://bit.ly/iDPUXY でも説明されているんだけど、 #scala

kmizu @kmizu

デフォルトの状態で、 implicitなCanBuildFromのインスタンスがが一体「どっから湧いてくる」のかについての説明が不十分だと思う。 #scala

Kenji Yoshida @xuwei_k

[壁]_・)ﾁﾗｯ <- CanBuildFrom

病気の美少女 @lyrical_logical

CanBuildFrom 一見魔術目いてるけど、役割も仕組みも簡単なんだけどなあ。まあすくみずさんがなんか書くならいいか

kmizu @kmizu

CanBuildFromの謎 http://bit.ly/kNeeHq にも書いたんだけど、多相的なimplicitな値の定義方法が以外と知られていないようなので、書いておく。(続く) #scala

kmizu @kmizu

通常、implicitな値はimplicit objectまたはimplicit valによって定義するけど、implicit defでも定義できる。たとえば、 implicit def X: Int = 10 と書いたら、Int型のimplicitな値を定義したことになる。

kmizu @kmizu

implicit def X = 2; のように書いた場合、毎回Xが呼び出されるので、その分のコストがかかるが、一方で、implicitな値を、随時計算できるというメリットがある。 #scala

kmizu @kmizu

で、多相的なimplicitな値というのは、implicit def canBuildFrom[A]: CanBuildFrom[List[_], A, List[A]] = ... のようにして書く。そうすると、 (続く) #scala

kmizu @kmizu

あらゆる型Aについて、CanBuildFrom[List[_], A, List[A]] 型の implicitな値が定義されたことになる(正確には、implicitな値を計算できる0引数メソッドだが)。 #scala

kmizu @kmizu

もちろん、制約をかけることもできる。たとえば、型パラメータの上限境界/下限境界の指定による制約も可能だし、

kmizu @kmizu

implicit def canBuildFrom[A](implicit req: Numeric[A]): CanBuildFrom[List[_], A, List[A]] = ... みたいにAについてNumeric[T]なimplicit parameterが

kmizu @kmizu

無ければダメポ、とかいうのも書ける。

しいたけ @yuroyoro

CanBuildFromについては、元コレクション型から変換先の型への変換関数をオブジェクトにしてimplictで引き回せるようにしただけの仕組み、と理解してる

kmizu @kmizu

これに関連した話として、implicit conversionは再帰できるという技もある。昔、型レ会で発表したころよりもわかりやすくしてみた。 http://bit.ly/mRsWtG #scala

kmizu @kmizu

型レ会で発表したときは、Rep[T]型みたいなのを作ってたけど、あれ、今考えると要らなかった気がする。なんで入れてたんだろ。 #scala

Nobuo Yamashita @nobsun

@kmizu その複雑さはユーザーが望んだものではないのかしら？

kmizu @kmizu

@nobsun また、それ以外の層(主にJavaユーザ)にとっても、サブタイピング(正確にはnominal subtyping)が無いのは困ると思います。でないと、Javaとの相互運用性がかなり下がるので。

kmizu @kmizu

@nobsun 多相性についても、better Javaとしての実用的な静的型付け言語を目指す上では、必須だったと思います。

kmizu @kmizu

@nobsun あとは型クラス(implicit parameter)や型コンストラクタ多相とかが必要だったか、ですが、これらは型システムを複雑にするので、別の形で同じような機能を提供するべきであった、かもしれません(それが何かはちょっとわかりませんが)。

Nobuo Yamashita @nobsun

@kmizu 具体的な内容を理解していないので素朴なクエスチョンです．これは概念として複雑になるということですか？それとも利用する仕組みとして複雑になるとうこと？ > 「これらは型システムを複雑にするので...」

kmizu @kmizu

「言語の複雑さ」といっても、実は人くくりにできるものではなくて、 (1) ad hocに色々な機能を追加していった結果、プログラマが覚えるべき規則が非常に多数になってしまう場合

kmizu @kmizu

(2) 機能の数はそれほど多く無いが(ので、覚えるべきルールの数もそれほど多く無い)、各機能の直交性が高いので、組み合わせることによって、複雑なことができてしまう場合

kmizu @kmizu

この２つの場合に大別できると思う。厳密に言うと、2) のケースは、言語自体が複雑ではないのだけど、ルールを理解していない間は、複雑に「見えて」しまう。