web-dev-qa-db-ja.com

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

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

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

language-designscriptingdslruntime
10
Jé Queue

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

IMO、Python（ホストシステムが.NETまたはJavaの場合はIronPythonまたはJython）またはRuby（IronRuby、JRuby））のような言語は、 JavaまたはC＃よりも上のDSL。

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

一部の長所：

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

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

2
Henrik

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

2
eggsyntax

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

1
SK-logic

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

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

1
Olha Pavliuk