問題タブ [dsl]

古い .Net Rocks を聞いていたところです。DSL の #329が興味深いと思いました。私の問題は、この技術を学ぼうとしている人々のための適切なオンライン リソースが見つからないことです。新しいデザイナーを作成するための基本は理解できましたが、DSL ツールで使用される T4 エンジンに関する MS ドキュメントと、テンプレートを DSL モデルに統合する方法が不足しています。

MS DSL ツールの優れた入門リソースを知っている人はいますか?

金融分野でDSL (ドメイン固有言語)を使用したことのある人はいますか? 私が取り組んでいるアプリケーションにある種の DSL サポートを導入することを計画しており、いくつかのアイデアを共有したいと思います。

私は、どのドメイン要素が最も安定しているかを特定し、DSL でより適切に実装される機能を選択する段階にあります。この最初の機能の構文はまだ定義していません。

ドメイン固有言語が飛び交い、ビジネス ロジックの扱い方がどのように変化するかについて、ますます耳にします。また、Ayende のブログ投稿やその他のことも見てきましたが、なぜ自分のビジネスを引き継ぐのかを正確に把握したことはありません。プロバイダーで使用しているメソッドや状況から離れたロジック。

これらのものを使用した背景がある場合は、本当の素人の言葉でそれを置くことができます:

• DSL の構築とは正確には何を意味するのでしょうか?
• どの言語を使用していますか?
• DSL を使用する意味があるのはどこですか?
• DSL を使用する利点は何ですか?

ユーザーが編集可能なある種のルール システムを実装する必要があることがよくあります。一般に、要件は十分に異なるため、同じシステムを直接適用することはできません。そのため、同じ問題に頻繁に遭遇します。ルール システムをどのように設計すればよいかということです。それ

1. 維持可能です
2. 表現力と使いやすさの適切なバランス
3. 簡単に拡張できます（（2）が間違っている場合）。

ルール システム/DSL は非常に価値があると思いますが、それらを適切に設計する能力に自信がありません。

これを簡単にするのに役立つ参考資料やヒントは何ですか?
私が遭遇する問題の性質上、既存の言語は通常適用できません。(たとえば、一般的なコンピューター ユーザーがメール フィルターを作成するために Python を学習する必要はありません。) 同様に、一部の (より単純な) ユーザー インターフェイスを構築する必要があるため、JESSなどのルール言語は部分的なソリューションにすぎません。 -ルール言語の最上位にあるため、プログラマー以外でも使用できます。このインターフェイスでは、必ず一部の機能を削除したり、それらの機能をより使いにくくしたりする必要があり、そのプロセスは上記と同じ問題を引き起こします。

編集：明確にするために、質問はルールエンジンの設計に関するものであり、事前に構築されたルールエンジンを探しているわけではありません。ルール エンジンを提案する場合は、それが適切な設計上の決定を下すことに関する質問にどのように対処するかを説明してください。

私の DSL プロジェクトには、ドメイン クラスのプロパティにリンクされた多数のデコレータを含むシェイプがあります。しかし、ieach デコレータには DisplayName プロパティ (意味のある値に設定) がありますが、生成された DSL プロジェクトには表示されません。（t4ファイルを再生成することを忘れていません。）

表示したい値として表示名のみを持つプロパティごとに別のデコレータを作成する必要がありますか、それとも今はわからない他の方法がありますか?

ここでは、Google は私の助けにはなりません。私は、ここが質問するのに最適な場所であることを知っています。

DSL 用のカスタム DirectiveProcessor を作成しており、T4 テンプレート内からダイアグラムにアクセスできるようにしたいと考えています。

DirectiveProcessor 内で、ドメイン モデルとダイアグラムを (待って...) LoadModelAndDiagram(...) を使用してロードしました。

これで、ダイアグラムはストアの既定のパーティションに読み込まれましたが、後でそれへの参照を解決する方法を見つけることはできません。

誰でも道を案内できますか？

本物の正直な外部 DSL を構築するためのツールはありますか? いいえ、Ruby、Boo、XML、または別の既存の言語や構文を悪用することについて話しているのではありません。つまり、本当の外部 DSL を意味します。つまり、自分の目的のための自分の言語です。

開発中の言語ワークベンチがいくつかあることは知っており、.NET の「Irony」などについて聞いたことがあります。もちろん、ANTLR、Lex/Yaac などもありますが、私がやろうとしていることには複雑すぎるのではないかと思います。

あなたが使用した、または聞いたことがあるかもしれない DSL ビルダー ツールと、それがどのように役立つか、およびその欠点についての印象について話してください。

数日前にこの質問をして以来、私の DSL は大きく進歩しました。

コードをリファクタリングしたらすぐに、それに対する独自の回答を投稿しますが、今のところ、別の問題が発生しています。

DSL で作成されたモデルからサブダイアグラムを動的に生成し、それらのダイアグラムを画像として保存してから、それらの画像が埋め込まれた Word ドキュメントを生成しています。ここまでは順調ですね。

しかし、私の図形にコンパートメントがある場合 (たとえば、サービス コントラクトの操作 - それが何かわかりますか?)、コンパートメント ヘッダーは表示されますが、アイテムは表示されません。

シェイプ オブジェクトを調べると、1 つのネストされた子 (ElementListCompartment) があり、これには、表示されると予想される多数の項目があります。ElementListCompartment.IsExpanded プロパティは true に設定されています (また、コンパートメント ヘッダーには小さな「折りたたみ」アイコンが表示されています) が、アイテムはどこにあるのでしょうか?

を使用して図形が図に追加されました

それで、誰かが私の楽しい道を案内してくれませんか?

Aliceのルールシステムによく似た、テンプレートのようなエディターで DSL を作成しています。ユーザーは、リストから関係を選択したり、関係を適用するオブジェクトを選択したりできます。これら 2 つのリストは、許容可能なタイプに基づいてフィルタリングする必要があります。たとえば、関係が「より大きい」場合、使用可能なオブジェクトは「より大きい」が実装されているタイプである必要があります。

同様に、より大きいと比較できないオブジェクトが選択された場合、その関係は潜在的な関係のリストに含まれるべきではありません。この問題の核心は型チェッカーにあると思いますが、その型のロジックをアプリケーションに組み込む最善の方法は確かではありません。DSL 用の既存の型チェック ライブラリを知っている人はいますか?

特にオープンソースとクロスプラットフォームのテクノロジーに興味があります。Java はおそらく私たちが最終的に使用することになる言語ですが、それは修正されていません。

私が書いているサーバーは、すべての人と直接接触するわけではありませんが、さまざまな人によって実行されると予想されます。サーバーはクラスター内で相互に通信します。サーバーの機能の一部には、潜在的に非常に大きなテーブルから行の小さなサブセットを選択することが含まれます。どの行を選択するかを正確に選択するには、ある程度の調整が必要です。また、クラスターを実行している人 (例えば、私自身) が選択基準を更新できることが重要であり、すべてのサーバー管理者に新しいバージョンのサーバーをデプロイしてもらう必要はありません。 .

実行時に任意の Python コードをダウンロードして実行するサーバーをインストールしたいと思う人はいないため、単純に Python で関数を記述することは実際には選択肢ではありません。

私が必要としているのは、この目標を達成するためにドメイン固有言語を実装する最も簡単な方法に関する提案です。この言語は、単純な式の評価だけでなく、テーブル インデックスのクエリと返された行の反復処理も実行できる必要があります。言語の書きやすさと読みやすさは、実装のしやすさに次ぐものです。また、クエリ オプティマイザー全体を作成する必要がないことも望んでいるため、クエリするインデックスを明示的に指定するものが理想的です。

これをコンパイルする必要があるインターフェースは、App Engine データストアがエクスポートするものと同様の機能を備えています。テーブルの任意のインデックスで連続した範囲を照会できます (たとえば、より小さい、より大きい、範囲、等値のクエリ)。 、次に、返された行をブール式でフィルタリングします。複数の独立した結果セットを連結することもできます。

この質問は、私が SQL を求めているように聞こえると思います。ただし、このデータを支えるデータストアがリレーショナル データベースであることを要求したくはありません。また、SQL を自分で再実装しようとするオーバーヘッドも必要ありません。また、既知のスキーマを持つ単一のテーブルのみを扱っています。最後に、結合は必要ありません。はるかに単純なものがはるかに望ましいでしょう。

編集：いくつかの誤解を解消するために説明を拡張しました。