DSL境界

ドメイン特化言語の話題になると、よくある疑問の1つは、何がDSLで何がDSLではないかということです。問題は、DSLには正確な定義がなく、DSLとその他のものの間には大きなグレーゾーンがあることです。

私にとって、重要な要素は、DSLは範囲（特定のドメインを参照する）と能力（汎用言語の基本的な機能を欠いている）の両方に制限されていることです。その結果、優れたDSLは通常、小さくシンプルです。「小さな言語」や「ミニ言語」といった用語が用いられるのもそのためです。

内部DSLの場合、あいまいな境界は、APIとDSLのどちらであるかということです。基本的に違いはありません。内部DSLは、単に派手な名前のAPIです（古いベル研究所のことわざにあるように、「ライブラリ設計は言語設計である」）。しかし、それにもかかわらず、DSLのような感覚で書かれたAPIを使用する場合、異なる感覚があると思います。Fluentインターフェースのようなものは、APIの操作を質的に異なる体験にすることができます。DSLの観点から考えると、可読性を異なる方法で考え、ホスト言語の構文を利用して、独立して存在するように見えるものを作成します。 rakeはこの素晴らしい例です。

外部DSLの場合、問題は、DSLと汎用言語（GPL）の違いは何であるかという形でよく提起されます。多くの場合、明確な兆候は、DSLがチューリング完全ではないか、抽象化機能を欠いている場合です。正規表現はこの能力の制限の良い例です。SQLはより興味深い候補です。それは複雑で強力な言語ですが、チューリング完全性と新しい抽象化を構築する能力の両方を欠いています。

言語はチューリング完全でありながら、DSLでもあることができますか？Ploticusのスクリプト言語はチューリング完全ですが、Ploticus内でグラフを作成することに明確に焦点を当てているため、少なくとも私にとってはDSLです。しかし、XSLTはどうでしょうか？これもXML文書の変換に限定された焦点がありますが、多くの機能を獲得したため、ますます多くの人がGPLと考えています。

Ploticusの例は、埋め込み言語がDSLかどうかという疑問を提起します。Excelのマクロ言語は、Visual Basicとほぼ同じである場合、DSLですか？汎用スクリプト言語をアプリケーションに埋め込むとどうなるでしょうか？

内部DSL対APIの問題と同様に、言語作成者とユーザーの両方の意図がここでの鍵だと思います。XML文書を変換するためだけにXSLTを使用する場合、出力文書に値を埋め込むための高度な呼び出しを行ったとしても、DSLとして扱っています。しかし、それを8クイーン問題を解決するために使用する場合、GPLとして使用しています。XSLTの設計者がXML変換に関するものと考えている場合、賢い人々が不自然な行為をする場合でも、DSLとして考えています。

これは、パブで話すのは面白い議論ですが、DSLを使用することの良いアイデアから注意をそらすべきではありません。DSLは、単一の課題に密接に焦点を当てた限定的な言語として設計する必要があります。そのアイデアを最優先に設計と使用に入れば、役立ちます。結局のところ、本当に重要なのは有用性です。