Domain-Specific Languagesにおける外部DSLの種類

Martin Fowler氏のDomain-Specific Languagesをほぼ読了。外部DSLについて、複数の手法がでてきたので、すこし整理。

DSL本では、外部DSLを実装する方法として、大きく以下の3種類が登場している。

  1. Tree Construction
  2. Embedded Translation
  3. Embedded Interpretation

Tree Construction

DSLから抽象構文木を生成し、tree walkをしながら意味モデル(Semantic model)を生成する方法。Gothic Securityの例でいうと、以下のイメージ。

f:id:GOLEM-XIV:20110101221854p:image

特徴と使いどころ

DSLコードから意味モデルの生成を、2パスの処理(1パス目:DSL→抽象構文木、2パス目:抽象構文木→意味モデル)で行う。中間形式である抽象構文木を導入することで、意味モデルへの変換処理という複雑なタスクを、より単純な2つの処理へ分割する。結果、実装やテストの容易性を高めることが可能。

よって、ある程度複雑なDSLや意味モデルとなるケースで有効な方法である。例えば、前方参照を扱う場合、1パスの方法にくらべ、容易に実装できる。

また、DSLコードから抽象構文木の生成には、ANTLRのようなparser generatorを使用することができる。

Embedded Translation

DSLから、直接意味モデルを生成する方法。同じくGothic Securityの例でいうと、以下のイメージ。

f:id:GOLEM-XIV:20110101222343p:image

特徴と使いどころ

DSLコードから意味モデルの生成を、1パスの処理で行う。多くのDSLは単純であり、わざわざtree-walkする必要もなく、Embedded Translationで十分な場合が多い。ただし、前方参照のような、複雑な処理を行う場合には、コードに工夫が必要となる。

ANTLRなどのcode generatorを使用して実装する場合、文法ファイル中のactionに、意味モデルの生成ロジックを記述することとなる。

Embedded Interpretation

DSLから(意味モデルを生成せずに)実行結果を算出する方法。parser generatorのチュートリアルでよく扱われる、計算式の文字列を与えると、計算結果を算出するようなプログラムが該当する。

f:id:GOLEM-XIV:20110101222344p:image

特徴と使いどころ

この方法では、意味モデルを生成しない。意味モデルが不要であるような、非常にシンプルなケースで用いることができる。

実際のアプリケーションでは

Martin Fowler氏が繰り返し述べているとおり、DSLでは意味モデルが重要である。ある程度複雑なドメインを扱う業務アプリケーションの分野では特に、意味モデルは高い重要性を持つ。よって、Tree Constructionか、Embedded Translationを用いることが一般的と考えられる。

また、自分で手を動かしてみたところ、ANTLRなどのparser generatorを使用すれば、ASTを作るのは、ほぼ自動。そして、ASTから意味モデルを生成するのは、DSLから意味モデルを1パスで作成するに比べ、容易である。よって、よっぽどシンプルなDSLでない限り、Tree Constructionを用いるのが一番適切なのではないだろうか。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です