kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

Re:Re:Re:不満の記録

Scala

主に型安全性に関する話について。必要悪的にそうなっているのであって、別にいい加減なわけじゃないよー、というScala擁護の話です。

つまるところ、ぼくが Scala に期待していたのは

  • Ruby のような快適さ (書きやすい文法に豊富な便利メソッドなど)
  • OCaml/Haskell のような堅牢性 (主に型安全性; 型推論が弱いのはともかく)
  • 速さ

だったんですが、どうやら堅牢性のところは大分いい加減に扱われているんだなあ、というのが現時点の印象です。

http://d.hatena.ne.jp/ku-ma-me/20090615/p1

まあ、OCamlやHaskellほど堅牢性を重視しているかと言われると確かに違うのですが(変数の未初期化バグの話は確かに擁護しづらい)、(特に型安全性について)いい加減に扱っているかというとそうでも無い、と私は思います。

asInstanceOfやGeneric型に対する型パターンマッチなどの「安全じゃない」機能は限られているので、使いさえしなければOCamlやHaskellと同等とは言わないまでも、それに近いレベルの堅牢性は得られます。「安全じゃない」機能がどれかさえ知っておけば、それらが使われていない箇所で不安に思うことはそれほど無いです。

ならば、「安全じゃない」機能は簡単に使えないようにすべき、というのは一理あります。しかし、ScalaはJavaのライブラリを呼び出さないとしたい事ができない事が多いので(HaskellやOCamlが基本的にはその言語のライブラリだけで完結できる事が多いであろう事と対照的に)、その辺を制限しちゃうと、不便な場面が多くて仕方が無いわけです(返り値をキャストして使う事を前提にしたライブラリのメソッドとかが珍しく無い)。Scalaだけでほとんどの部分を完結できるならその方がいいとは僕も思うのですが、ネットワーク、GUI、ファイルI/Oなど、Javaライブラリと協調しないとやってけない部分があまりに多過ぎるので(今後のバージョンアップによって、標準ライブラリによってカバーされる範囲は増えて行くとは思いますが)。

つまり、「安全じゃない」機能が簡単に使えるようになっているのは、どちらかというとJVMの上でScalaが実用言語としてやっていくための必要悪みたいなものであって、Scalaが言語として安全性を重視していないとかいい加減に扱っている、というわけでは無いのだと理解しています(意図せず型安全じゃなくなるケースについては、基本的に、Generics型に対する型パターンマッチのようにちゃんと警告が出ますし。いい加減に扱っているならそもそも警告も出さないだろうと思うわけです)。

ちょっと追記。catcnの中のパターンについて：

そういえば catch の中が型にマッチするパターンなので悩ましいですね。

問題になるのは、型にマッチするパターンかつ型がGenericなときだけなので、

//GenericなException。普通は使わない
class GenericException[X](...) extends Exception

//安全ではないので、警告が出る
try { ... } catch { case e:GenericException[String] => ... }

みたいなことさえしなければこの点については問題無いです。

class AnException(...) extends Exception

//こっちは安全
try { ... } catch { case e:AnException => ... }

さらに追記：
書いた後、考え直してみたのですが、そもそも抜け道的な機能をユーザからどの程度容易に使えるようにするかは、言語自体の型安全性(あるいは堅牢性)とは、あまり関係ない話ではないかと。たとえば、OCamlのObj.magicだって黒魔術扱いされてはいるものの、ユーザから普通に使えないかというとそういうことは無いわけであって、じゃあOCamlは堅牢ではないとか型安全ではないとかというとそうじゃないだろうと思うわけです。