なお、Asakusaについての調査は、あくまで斜め読みですので、誤解してる箇所についてはご容赦頂き、指摘して頂けると有難く思います。
言語指向フレームワークとしてのAsakusa
Asakusaは、技術的な面だけでざっくり言うと、Hadoop用のMapReduceコードを生成するフレームワークで、開発者ロールによって異なる３種類のデータフローDSLと、データモデルDSLを持っている、本格的な言語指向フレームワークと理解しました。
- 現時点で、データフローDSLはJavaをホスト言語とする言語内DSLで、データモデルDSLは専用の外部DSLのようです。このJava DSLは、実行時リフレクション方式ではなく、静的コード生成方式のようです。
- Javaをホスト言語とする言語内DSLは一見珍しい気もしますが、アノテーションによるメタプログラム(DSL)からAPTでコード生成を行うのは、Javaによる静的メタプログラミング手法の一つであり、Slim3でもそうしたものを伺えます（だからといって真似が簡単だというわけでもないです...）。
- 一方、データモデルDSLはDMDLスクリプトと呼ぶ外部DSLであり、DMDLコンパイラによってJavaモデルコードを生成するようです。
- データフローDSLの場合も、データモデルDSLの場合も、結果として静的にJavaコードを生成する原材料で、Hadoop実行時には生成MapReduceコードが走る仕組みのようです。
Javaだけじゃない、ScalaによるDSL定義
ちょっと情報を探してみると、AsakusaデータフローDSLをJava以外の言語でも記述できるようにする計画があるらしく、最初の実装としてScalaが検討されているようです。
Javaの場合もScalaの場合も、汎用プログラミング言語内DSL(Scalaの場合はホスト言語内DSLとは言えない感じなので)ですが、いずれの場合も実行時方式ではなく静的コード生成方式なのは同じようです。
また、このような複数のDSL表現言語から、共通に利用できる内部表現形式を定義する予定もあるようです(もうあるのかもしれません)。
さらに、AsakusaのDSLコンパイラは、データフローを最適化圧縮する仕組みがあるらしく、内部表現形式がDSL定義言語から独立することで、このオプティマイザも再利用できるようになると思われます。
言語指向の王道設計パターンと言えばその通りですが、それがHadoopのような領域で実用となると、とてもすごい応用ですよね。
AsakusaにXtextを適用できるか
さて、このAsakusaのDSL定義として、Xtextを適用できるかどうかを、ぼんやり考えてみたので、ざっとメモとして挙げてみます。なお、設計や実装、ドキュメントに詳細に当たったわけではないので、かなり想像/妄想で考えていることについては、ご了承ください。誤りがある場合は、ご指摘頂けると有難いです。
- AsakusaのメタプログラムDSLは、実行時リフレクションではなく静的コード生成方式なので、まずはXtextが行けそうな分野です。
- Asakusaが、汎用言語内DSLを採用しているのは、エディタなどのDSL技術開発生産性や、IDEによる開発との親和性を考えてのことのようなので(出典)、この点はまさにXtextの得意分野と言えると思います。
ただし、XtextのDSLエディタは、Eclipseプラグインとして生成されるので、DSLエディタ機能がEclipseにロックインされてしまうという、若干の懸念はあります(パーサなどはその限りではないです)。 - AsakusaのDSL内部表現形式については、現時点では恐らくPOJOとして実装されているとは思いますが、それがEMFモデルとして定義されると完璧にXtextと調和します。
AsakusaのDSL内部表現形式は、ランタイムでHadoop上で動作するものではなく、Javaコード生成に使われるだけのものだと思うので、EMFのランタイム特性については、気にする必要が無いと思います。 - EMFで表される内部表現からのJavaコード生成も得意分野だと思います。
自分はまだ不勉強ですが、XtendとMWEでJavaコードを生成するイメージになると思います。 - Asakusaのワークフロー最適化については、DSL実装/内部表現形式/オプティマイザが全て独立していることにより、オプティマイザは再利用可能なので、Xtextを適用しても影響ないと思います。
- ワークフローDSL以外に、DMDLからのJavaモデルコード生成にも、上記と全く同じ考え方で、Xtextを採用できると思います。
ワークフローDSLは汎用言語内DSLとし、DMDLは外部DSLとしていることで、現状はそれぞれ別なDSL表現技術となっていると思いますが、Xtextを使って両方とも外部DSL方式とすれば、同じDSL表現技術で統一することができます(それが良いことなのかは自明ではありませんけれども...)。 - DSLエディタやコードジェネレータの実装コストについては、Xtextでかなり削減できるのは間違いないですが、エディタにJDTほどの使い勝手を求めるとなると、(それが偉大であるが故に)結構な手間がかかることが想像できます。この辺については、まだ自分も突き詰めていないので、まだハッキリとはイメージできません。
- Xtextを使って外部DSLとすることで、汎用言語内DSLでの実装に比べて、構文ノイズを確実に減らすことができます。これは、ユーザにとってメリットだと思いますし、コンサルティング上も有利に働くような気がします。
- ホスト言語が持つ汎用機能は完全に使えなくなるため、DSLに対する制約の実装は確実に容易になります。この辺りでコストが下がれば、DSLエディタの使い勝手を向上させるコストに回せそうな気がします。
浅い理解
まだまだいろいろな検討事項があるとは思いますが、自分の中に沸き上がった興味については、一通り挙げられたように思います。
ただし上記の検討は、あくまでDSL一般論としてであって、自分はまだHadoop MRの仕組みや、Asakusaワークフローについて本質的に理解していないので、DSLの複雑性を過小に見積もっている可能性が高いです。その結果として、汎用言語内DSL方式からXtextによる外部DSL方式に移行するコストが、ごっそりと過小評価されてしまい、上記の検討が完全に外れた内容になっている可能性もあります。その点については、今後知識をアップデートしていきたいと考えています。
汎用言語内DSL方式に対して、外部DSLを作成するコストを、どれくらい抑えることができるのかは、Xtextにかけられる大きな期待の一つだと思いますし、自分がXtextを今後活用して行く上でもとても気になる部分です。
Asakusaをネタにしていろいろ検討することで、また少し検討が深まった気がします。
0 件のコメント:
コメントを投稿