DSLの例外性

外部ドメイン特化言語について書くことの難しい点の一つは、プログラミング言語コミュニティによって既に深く掘り下げられた領域を歩いているということです。プログラミング言語の研究は常に学術活動の人気のある分野であり、この分野を長年研究してきた多くの人々ほど、このトピックについて深い知識を持っていないことを最初に認めなければなりません。ですから、必然的に、私のような初心者が、なぜこのよく踏み固められた地で本を書くことができると考えているのかという疑問が生じます。

主な理由は、DSLに関する実践者向けの本を他に誰も書いていないからです。私は、このようによく踏み固められているが、よく書かれていないトピックが好きです。しかし、これらの道を歩いているうちに、別の要因が働いていると思います。

プログラミング言語に関する多くの研究がありますが、そのほとんどは汎用プログラミング言語に集中しています。DSLは、汎用プログラミング思考の小さくて単純なサブセットと見なされています。その結果、人々は汎用言語に当てはまることはDSLにも当てはまると考えています（DSLは小さすぎてあまり考える価値がないことを暗に示しています）。

私はますます反対の結論に達しています。DSLのルールは、汎用言語のルールとは異なります。これは複数の次元で当てはまります。

最初は言語設計です。私は非常に尊敬している言語設計者と話しましたが、彼は言語の重要な特徴は新しい抽象化を定義する能力であると強調しました。DSLでは、これは当てはまらないと思います。ほとんどのDSLでは、DSLが使用する抽象化を選択します。異なる抽象化が必要な場合は、異なるDSLを使用します（または、使用しているDSLを拡張します）。新しい抽象化の役割がある場合もありますが、そのような場合は少数であり、発生した場合でも抽象化は制限されます。実際、新しい抽象化を定義する能力の欠如は、DSLを汎用言語と区別するものの1つだと思います。

違いは、言語に付属するツールを実装するために使用するアプローチにも発生します。汎用言語の恒常的な問題は、現実的なプログラムには数千または数百万行のコードが含まれるため、大量の入力を処理することです。その結果、それらを使用するための多くのツールとテクニックには、解析を理解しにくくするが、これらの大量の入力をサポートする側面が含まれます。DSLスクリプトははるかに小さくなる傾向があるため、これらのトレードオフは異なって機能します。

私の仕事では、DSLを使用してセマンティックモデルにデータを入力し、そのモデルをそれ以降の処理（解釈、視覚化、またはコード生成）の基礎として使用することに重点を置いてきました。私が見てきた多くの言語の作成では、コード生成、多くの場合、文法ファイルから直接コードを生成することに重点が置かれています。中間表現についてはあまり語られておらず、出現した場合でも、セマンティックモデルではなく抽象構文木の形式であることが多くなっています。本格的なコンパイラは、プログラム依存グラフなどの中間表現を使用しますが、これらは（当然のことながら）高度なトピックと見なされます。セマンティックモデルは、DSLの使用を簡素化し、解析とセマンティクスを分離できるため、非常に貴重なツールだと思います。

DSLは表現力が低いため、より単純な言語を設計できます。言語コミュニティの著作の多くは、複雑な汎用言語の難しさをどのように処理するかについて述べていますが、DSLSの課題は、対象の読者（非プログラマーを含む場合もあります）が理解しやすく、解析しやすい（パーサーのメンテナンスを簡素化するため）言語を作成することです。これは、言語の設計に関する異なる決定につながるだけでなく、パーサージェネレーターの機能のサブセットのみが必要になることも意味します。

この結果、個々のDSLが目の前の問題全体を解決することはなく、多くの場合、DSLを組み合わせる必要があるという期待を持ってDSLが記述されます。従来の言語の考え方では、構成可能な言語のアイデアはそれほど探求されていませんが、DSLが発展するにつれて、このトピックは非常に重要だと思います。構成可能な言語について考えることは、言語設計と言語ツールの両方に大きな影響を与えるはずです。

そのため、私はますます、DSLはプログラミング言語についてのいくつかの非常に異なる考え方をもたらすという考えに至っています。また、DSL作業により適した、通常はより単純な、異なる種類の解析ツールの開発につながる可能性もあります。近頃DSLへの注目が高まっていることで、より多くの人々がDSLを汎用言語の単純な形式ではなく、第一級の研究対象として扱うようになることを願っています。