Scalaのメソッドと関数は違うもの？

kinaba @kinaba

http://twitter.com/kmizu/statuses/84424219621990401 以下を見ていて思うに、混同が多く起こるような概念は、説明がきちんと区別すべき、ではなく、そもそもそれが同一概念になるよう言語を設計すべき、ってのが理想型かなあという気がしている

kinaba @kinaba

もちろん後者の方が遙かにハードだし他の様々な事情もかかわってくるし、現実的でもないし、Scalaやそのチュートリアルがそうすべきであるという意図ではまったくないです念のため。

akihiro @akihiro4chawon

2ch のスレを見た。「共著の弊害として章・節ごとに品質にばらつきがある」というのは、あまり正確な言い方ではない。少なくとも、2章から3章を読み進めて、品質に差があるとは感じ無かった。

akihiro @akihiro4chawon

ただ、共著の弊害があるとすれば、2章では、関数とメソッドの違いを3章ですると書かれているけれど、3章でその説明はどこよー？みたな感じだった。そういうのが共著の弊害ではないだろうか。

akihiro @akihiro4chawon

ちなみに dpp の scala プログラミング入門は、メソッドと関数(FunctionN)の違いをきちんと説明している入門書。それで、ちゃんと説明してくれているんだけれど、部分適用と関数のあたりからむずいなーと思い出して P.105 にこんな付箋を貼った「難解なので読み飛ばす」

がくぞ @gakuzzzz

うーん… Scala が FunctionNとメソッドを区別してるのは JVM ではフィールドがポリモーフィックに動作しないから実装の都合上しょうがなくそうしてるってだけじゃないのかなぁ？ 概念としては同じにしたいんじゃないだろうか。 #scala

がくぞ @gakuzzzz

あー あと型パラメータの問題があるのか。型パラメータ付きフィールドって何かおかしいもんね。型パラメータの問題さえなければ def は val で FunctionN を定義する Syntax Sugar ってできそうなのになー。 #scala

kmizu @kmizu

@gakuzzzz はい。型パラメータ(多相型)の問題が入ってくるので、話がややこしくなります。Javaのメソッドとの互換性を保つという実用上の都合もありますが。 #scala

がくぞ @gakuzzzz

@kmizu ですよね。この辺がすっきりと整理できればもうちょっとシンプルに人に伝えられるのかなーと思ってます

がくぞ @gakuzzzz

個人的には関数型の概念を伝える状況では FunctionN と メソッドは同じ概念として伝えたほうが理解されやすいかなと思ってます。Scala の実装詳細を伝える状況では現実に対応するために明確に区別されてる事を伝えたほうがいいと思いますが。 #scala

kmizu @kmizu

@akihiro4chawon 関数とメソッドの違いは3章p.157-p.158で説明してあるのですが、2章で3章のどこで説明する、という事をちゃんと説明していなかったのが悪かったですね。すいません。

kmizu @kmizu

@akihiro4chawon あと、それに加えて、3章p.170(カリー化と部分適用)でもその説明を再度行っています。読まれた上で、伝わらなかった、という趣旨でしたらすいません。 #scala

akihiro @akihiro4chawon

@kmizu おっと失礼しました。P.157-158 に書かれていることを見落としての発言でした。すみません。

sumim @sumim

なんでファーストクラスにしなかったんだろう→“Scalaでは、メソッドおよびその他のdefで定義されたものはファーストクラスオブジェクトではありません” - メソッド != オブジェクト - プログラミング言語Scala 日本語情報サイト http://bit.ly/iPl1qF

kmizu @kmizu

@kinaba 自分もそれが理想型だとは思います。ただ、既にある言語に対してはそうはいかないので、説明する方がなんとかしないと仕方無いというか。

kmizu @kmizu

Scalaのメソッドと関数について、混同が起こってしまったのは、説明の仕方以外に、メソッドが関数に自動変換されるケースがあるからだと思うんだけど、これを無くすとimplicit parameter周りで色々不便が起こるので無くすわけにもいかないだろうなあ…とか。 #scala

kinaba @kinaba

@kmizu はい、それは了解しています＞説明する方がなんとかしないと。あ、ただ、「既にある言語に対してはそうはいかない」という部分はScalaの空気としてそんな感じなんでしょうか。3.0向けにこれをどうにかする提案が百花繚乱、という展開もありうると思うのですが

kmizu @kmizu

@kinaba 3.0だと複数引数とタプル引数をunifyするという話は聞いたことがあるのですが、メソッドと関数の扱いをどうするか、は特に話に出てなかったですね。ただ、「メソッドもファーストクラスオブジェクト」に見えるように統一する案は考えられる気がします。 #scala

kmizu @kmizu

Scalaで「メソッドはファーストクラスオブジェクトだ」と主張できるようにする案。まず、メソッド名＋引数型列を合わせた変数が、メソッドオブジェクトを束縛している「ことにする」。 たとえば、obj.toString<> は0引数のtoStringメソッドオブジェクトを取り出す。

kmizu @kmizu

1 + <Int> は、 Int を引数に取るメソッドオブジェクトを返す(ということにする)。つまり、引数型まで名前の一部に入れれば、「メソッドはファーストクラスオブジェクトだ」と言い張ることはできそう。

kmizu @kmizu

で、例外規則として、型名を明示しなくてもわかるケースでは、勝手に適切なメソッドオブジェクトを選んでくれる(ことにする)。

kmizu @kmizu

実際の所、現在のScalaの仕様はそれにかなり近い形になっていて、たとえば、 obj.method _ で、methodがオーバーローディングされていたら、引数の型指定することで適切な関数オブジェクトを得られるようになっている。 #scala

kmizu @kmizu

あとは、そういう仕様にしたらどういう問題が発生しそうか、だけど、これは、implicit parameter周りの規則を調べてみないとなんともいえない。

akihiro @akihiro4chawon

オブジェクト指向のメソッドがダメな点な、常に第一引数が部分適用された形であること。もちろんこれは容易に解決可能だけれど、できれば、Object Pascal のメソッドポインタ(TNotifyEvent)のような形でunapplyできたらウレシイ。

akihiro @akihiro4chawon

このメソッドポインタを Scala でやろうとすれば、やはり implicit parameter が渡されるのはいつが妥当という問題が発生するのかな。