DSL/Defining Domain Specific Languages

ドメイン固有言語を定義する †

ドメイン固有言語とは、特定の領域に焦点を当て、表現が限定されたコンピュータプログラミング言語。
境界を考える際は、DSLを定義する4つの要素を満たしているか否かを考慮する。

ドメイン固有言語：特定の領域に焦点を当て、表現が限定されたコンピュータプログラミング言語。

DSLを定義するには、次の4つの要素がある

要素	説明
コンピュータプログラミング言語	DSLはコンピュータ言語である事
言語の性質	個々の表現から生成されるだけはなく、共に構成される事によって表現される流暢さも持ち合わせている事
制限された表現力	DSLはシステム全体を構築することは出来ず、ドメインの特定の側面のために必要な最低限のサポートしている事
ドメインフォーカス	制限されたドメインに対して明確な焦点を当てている事

DSLのスタイルは３つ

スタイル	説明
外部DSL	DSLを使用する主要な言語とは異なる言語を使用するDSLs XML等が一般的
内部DSL	汎用なプログラミング言語を使用する。ただし特定の分野、かつスタイルが制限されている。
言語ワークベンチ	DSLsを構築する為に設計されたIDEs

その他の特徴として、DSLは、通常のAPI呼び出しと異なる操作を提供しているフレームワークのフロントエンドと言える。

内部DSLにおける境界の考察（内部DSLとコマンドのクエリAPIの違い）
- この場合、境界を考える際の核心は言語の特性
- コマンドクエリAPIは語彙を定義するが、内部DSLは文法を追加するもの。
- 内部DSLは無関係なコマンドの連続というより、全ての文を統合するようなもの

外部DSLにおける境界の考察
- R言語に代表されるように、外部DSLはドメインフォーカスであるが、汎用言語が持っている全ての表現力を持ちあわせている物は外部DSLとは言えない。
- 正規表現は、ドメインフォーカスであり、変数も、サブルーチンを定義する事は出来ないので外部DSLと言える。
- XSLTの場合は、使用目的によって、DSLとも汎用言語ともなり得る。
- システムの側面と相互作用する為に、人が行う主要な方法を表現している場合は、DSLであると言える。

言語ワークベンチにおける境界の考察
- データ構造を形式を設計することを許容するアプリ（例：アクセス）間で存在する。
- 境界を考える際の鍵は、言語の性質。（流暢さを持っているかどうか）

スターバックスで交わす専門用語はDSLか？
- 結論を言えば「DSLではない」。
  「ベンティ」、「ハーフ・カフェ」、「ノンファット」、「ノーフォーム」、「ノーホイップラテ」といった人間が発する言葉は、ドメインフォーカスであり、
  語彙だけでなく、文法を定義する言葉であるが、「コンピュータ言語」ではない為。

序文の例としてあげた「秘密のパネル」に関するステートマシンの例は、独立したDSLの例
（スクリプトが単一ファイルである）
正規表現（外部DSLs）は断片化の良い例。
ホストコード内に全ての正規表現のファイルを持っていない替わりに所々に、正規表現に関する小さなスニペットを持っている。
アノテーションなどは、内部DSLにおける断片化の良い例。

大それたタイトルの割りに、内容がもやもやして消化不良で不満足・・・。DSLのスタイルに関する表までを抑えておけば良いのではと思います。
ドメイン固有言語を定義する
- あまり拘る必要もない気がしますが、ソース駆動言語って何でしょう？言語間のミスマッチを変換してくれる自動生成されるミドルの事？
  （渡邊さん曰く、「モデル駆動との対比の言葉で、既存のプログラミング言語を指しているのでは？」との事）
DSLsの境界
- 「人が行う主要な方法を表現しているか」というのが外部DSLの境界定義を考える際の１つの鍵になっているが、それなら何故「9×9クイーンズ」が駄目なんだろう？
- ステートモデルを採用し、リレーショナルデータベースの構造の中で表現するのは何故、悪い？
- FIT=Framework for Integrated Test、wiki　（渡邊さん、ありがとう！）

DSLsの断片化と独立性
- ここで言う断片化と独立性の違いは、呼び出し元で、一つの処理を完遂させる為に、ちょこちょことDSLが呼ばれているか否か？って言う事か？