DSL
Output Production Strategy †
一言要約 †
- セマンティックモデルを作るには、Embedded TranslationかTree Constructionを使うと良い。
- 一長一短なので、少し試してみてから選ぶのが良い。
要約 †
- ファウラーは、セマンティックモデルを構築することが必要だと主張している。
- 一方、既存の言語コミュニティーでは、セマンティックモデルなしで、直接、出力コードを生成することを、内在的な仮説としている。
- これは、汎用言語のための合理的アプローチだが、DSL向けに提案しているものではない。
- セマンティックモデルを作るには、次の方法がある。
- Embedded Translation
- １ステップで構築する方法
- パーズ処理中に、同時に、セマンティックモデルを作る。
- これは、通常、シンボルテーブルなど、中間解析データが必要になる。
- Tree Construction
- ２ステップで構築する方法
- まず、入力テキストをそのままあらわした構文木を作る。
- 次に、その構文木を歩き回って、セマンティックモデルを作る。
- Embedded Interpretation
- 解析プロセス中に実行もしてしまう方法。
- たとえば、電卓などかそれにあたる。
- つまり、セマンティックモデルは存在しない。
- セマンティックモデルなしで、Embedded TranslationとTree Constructionを使える。
- コード生成などではよく見かける。
- 単純な場合は、使えるが、セマンティックモデルのほうが圧倒的に役に立つ。
Tree Construction について
- 入力テキストをトークンに分解して、それをそのまま構文木として構築する。
- 最も単純なものは、入力テキストをすべて含んだ構文木(パース木)。
- テキスト構造をマークするもの(カッコとか、セミコロンとか)を排除して、抽象構文木(AST Abstract Syntax Tree)をつくる。
- その利点は、ふたつの単純なステップに分解する。(複雑な１ステップより簡単)
- 多くのパーサジェネレータは、ツリー構築を簡素化するのためのDSLを提供する。
- SAX を用いた Embedded Translation、DOM を用いた Tree Construction
まとめ
- お勧めは、Embedded TranslationかTree Construction。
- どちらが良いかは、中間木のコストによる。
- 複雑なものは Tree Construction のほうが良いことが多い。
- 中間木のメモリコストはいまやとても安いにもかかわらず、必ずしも Tree Construction が良いとは限らない。
- なぜなら、木構造を歩き回るコードを書くのは、問題になりやすいから。
- 両方を少し試してみて、どちらが良いか考えてみて欲しい。
ファウラーへのフィードバック †
- Typo : general putpose → general purpose
- Typo : reccomend → recommend
担当者のつぶやき †
- 原文での produce, product, create は、たぶんニュアンスが違うのだけれども、訳すときは全部「生成する」にしてしまった。
みんなの突っ込み †
