DSLの構築：汎用言語の上にスクリプト化されたものですか、それともスタンドアロンですか？

私は、特定のあいまいなプログラミングモデルを簡略化するために、ドメイン固有の言語を設計することについて議論しています。議論の一部は、既存の言語/ランタイム（Javaなど）の上にそれを（スクリプトとして）構築するか、それをスタンドアロン（独自のコンパイラ、＆c）にするかです。

DSL設計の経験がある方、長所/短所、または適切なアプローチに対する確実な答えはありますか？

既存の言語（内部DSL）の上にDSLを作成することをお勧めします。私はこれをPythonで数回行い、DSLのコンシューマーがシステムの構成ファイルとして使用されるpythonファイルを書き込むシステムを作成しました。構成ファイルは、私が定義した構成（クラス、関数）を使用します。これらの構成体がDSLを形成します。

IMOは、Python（ホストシステムが.NETまたはJavaの場合はIronPythonまたはJython）またはRuby（IronRuby、JRuby）のような言語であり、JavaまたはC＃よりもDSLの基礎として適しています。

私の場合、ホストシステムも（C）Pythonでしたので、DSLにPythonを選択するのは自然なことです。

いくつかの長所：

• 建物の低コスト。実装する必要のあるものがはるかに少なくなります。パーサー/コンパイラ/インタープリターの実装に時間を費やす代わりに、目の前の問題に集中できます。
• ホスト言語へのアクセス：あなたの言語は、既存の言語/プラットフォームの全機能にアクセスできます。

見てのXtext（http://www.eclipse.org/Xtext/）とのXbase（http://blog.efftinge.de/2010/09/xbase-new-programming-language.html）。ユーザーがプログラマーでない場合、DSLを既存のプログラミング言語に基づくべきではないと私は思います。彼らにとって複雑すぎるでしょう。「クリーン」なDSLは、正しく作成すれば非常に効率的です。

特定のアプローチを推奨するのではなく、Martin Fowlerのドメイン固有言語を、意思決定を行うための優れたリソースとして推奨します。これは、内部および外部DSLの相対的なメリットについて、幅広い、示唆に富む調査を行っています。

3番目のオプションがあります-汎用言語の上にコンパイラとしてDSLを構築します。C ++のような低レベルのものも含めて、ある程度のメタプログラミング機能を備えた言語であれば、どれでも機能します。私はこの種のものにはLispや類似の言語を好みますが、テンプレートHaskellやNemerleも同じレベルの柔軟性を提供できます。

Martin Folwerは、著書「ドメイン固有言語」で、内部および外部 DSL について説明しています。
Internal DSL= Ruby / Javaなどの既存のプログラミング言語のサブセットです。
External DSL=構文と語彙を定義します。
外部DSLはより表現力を高めることができますが、外部の解析とコード生成が必要になる場合があります。
内部DSLは追加の処理を必要としませんが、非プログラミングドメインのエキスパート（ビジネスアナリスト、テスターなど）にとって理解が難しい場合があります。

DSLのタイプを選択するときは、そのユーザーが誰であるかを分析することが重要です。彼らがほとんど技術者でない場合は、外部DSLの方が適しています。経験豊富なプログラマーの小さなチームの場合、使用するプログラミング言語が十分に表現力があれば、内部DSLを選択できます。