Matzにっき

_ [言語]Adding Optional Static Typing to Python

Python作者、Guido van Rossum自らPythonにオプショナルな静的型を導入することについて語る。 パート1。 パート2。

さすがはGuido、Python Type SIGでのさまざまな議論を反映しているとみえて、素晴らしいまとめである。 CLOS(とその派生系であるDylan)を別にするとまだ誰も成功していない 「動的言語における静的型」に必要な機能を不足なくカバーしているように見える。

• DuckTyping。提案ではデフォルトではsignature conformanceしか要求しないDuckTypingである。ただし明示的にクラス適合も指定できる。
• Generic Type。オブジェクト指向言語に静的型を導入するならば、かならず必要になる。型変数に型指定ができる(この型はある型のサブタイプである、とか)のが現代風。
• Overloading。型を指定するならば型の違う複数のメソッドを定義したい。
• Interface。「型」をまとめる単位としてのインタフェース。メソッドボディは提供できないが、アサーションは定義できるというのがちょっと珍しい。
• 型のUnion, Intersectionが指定できる

これだけあれば、静的型言語として足りないものはなさそうだ。 Generic Typeなどは多くの静的型言語(例: C++, Java)の設計者も当初は見落としていた(しかし後にその重要性に気付いた)ものなので、きちんと押さえていることはポイントが高い。

私が一昨年のRuby Conferenceのスライドで「Optional Static Typing」とさらっと書いたものに対して、 より深く、より完全な考察を行ったものだと考えてよいだろう。さすがだ。

しかし、このようにGuidoがまとめてくれたものを眺めて、改めて考えると、 やっぱ将来Rubyに静的型は導入するのやめようと思った。 たとえオプショナルでも。

理由は以下の通り。

• これだけ完備した型システムを用意しても、オプショナルでは効果は半減以下である。 しかし、RubyがRubyであり続けるためには必須にすることはできない。 完全な型指定を要求するのでは動的言語とは呼べないような気がする。 たとえ、ここで述べられている型システムが DuckTypingを採用した、いわば「動的言語フレンドリー」なものであるにもかかわらず。
• 「効果が半減」することが予想されるのにもかかわらず、 型の導入は言語を複雑化される。その複雑さは割りに合わないように思える。
• 効率の良い実装が思いつかない。私の知識や能力の限界かもしれない。

Guidoは

this is something that many people, especially folks writing frameworks or large applications, need

と書いているが、LispあるいはSmalltalkの実績は、必ずしも静的な型がなくても 大規模アプリケーションやフレームワークが構築できることを証明しているようにも思える。

というわけで、オプショナルな型システムは将来にわたってRubyに実装されることはないだろう。 もうちょっと簡易な(かつDuckTypingを意識した)型チェック機能の導入はありえるかもしれないが。