さらにもう一つの静的Groovy…Grumpyプロジェクト
旧聞に属するのですが、8月の頭ぐらいからGroovy-devのメーリングリストで、Groovyコアコミッターたち(の一部)による「"Grumpy"プロジェクト」なるものが始動していたことが話題になってました。 議論は、プロジェクトリードのGuillaume Laforge氏の休暇中に、HamletDRC2氏による「Should Static Type-Checked Compilation Come to Groovy?」と題するフライング気味のブログポストで明らかになったことから、当初波乱含みで始まりました。
Grumpyはいったい何かというと、ソースコードとかはまだ全然公開されてなくて、というより構想レベルみたいな感じですが、Groovyプロジェクトの技術リードJochen Theodorou氏によれば
Grumpy (project name, not actual name) will type check a Groovy program. Not all Groovy programs will pass this, so Grumpy will make a real subset of Groovy. Some things will most probably never compile. Part of this is the spread operator. Another example would be the regexp matching, were a Closure can have the number of matching groups as parameters. I am intending to make an annotation used by Grumpy that can express types more freely as strings.. for exmaple:
(拙訳)
Grumpy(プロジェクト名であり実際の名称ではない)はGroovyのプログラムの型チェックを行う。すべてのGroovyプログラムがこれをパスするわけではなく、だからGroovyはGroovyのサブセット化を実質的には行う。いくつかの機能はコンパイルされない。たとえば、展開演算子とか。あるいはクロージャが引数としてマッチンググループの個数を持つような正規表現マッチングとか。Grumpyで使われる構文は、型を文字列で自由に表わせるようにするつもりだ。たとえば:
とのことであり、ここで示されている例はこんなの。
@StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)") Object call(Object... args){...}
このアノテーションを人が書くというわけではなく、Grumpyが上のような型情報をGroovyの生成するクラスに付与する、ということのようです。
型推論で、ASTのレベルかバイトコードのレベルでノードに型情報を属性としてつけまくってくようなイメージですかね。わたしはこれでコンパイラの属性文法を思いだしました(rieとか)。Groovy 1.8でASTノードにメタデータを付ける機能がつきましたが、このプロジェクトでそれを活用しているかは全く不明です。
Grumpyは、高速化のためのものではなく、型安全確保の達成を目的とするものとのこと。もちろん、これが出来た暁にはGrumpyが生成した型情報を元にして高速化のための別プロジェクトが起動するかもしれないが、それはまた別の話。この意味で目的とするところがGroovy++とは異ります。
とはいえ、「静的型Groovy」といえばGroovy++とかなり重なるものであるため、両者の位置付けや使いわけ、将来について議論が沸騰していました。
Groovyのメインラインで静的型サポートの扱いがどういう方向性を持つかについて、一歩踏み出したのはいいけど、決着が付くのはまだ当分先って感じなのかな、という印象を持ちました。
ちなみに英単語としての"Grumpy"の意味を辞書で引くと、
とのことです。
