5つのDSLが独立に「抽象化追加だけ規約寄り」へ収束した
構成記述系DSL 11個を3自由度で点検すると、当初の4象限には現れていなかった第5象限が浮上する。Pkl / KCL / Dhall / Jsonnet / Nickelの5つが、独立に同じパターンへ収束している。
| 自由度 | これら5DSLの対応 |
|---|---|
| 抽象化の追加 | 規約に委ねる(高階関数 / lambda / 継承などが自由) |
| 複数量の制御 | 言語が決める(専用comprehension or組込み再帰子) |
| 実装の切替 | 言語が決める(import pathリテラル) |
これは「外部DSLを選びつつ、計算ロジックの再利用(関数)だけは汎用言語並みに開放し、graph/value形状を変える2自由度だけ言語で縛る」という共通の設計判断である。5つが互いに参照し合った結果ではなく別々に到達しているので、実用上の必要性 — 環境別パラメタ計算や命名規則ヘルパーを関数で再利用したい — からの自然な収束と読める。
重要な限定がある。この収束は構成データ出力DSLに限った観察である。5つはいずれもJSON/YAMLを出力するDSLで、graph形状の予測性が論点にならない。graph出力DSLでこの位置取りを実装した先例は存在しない。したがってgraph出力DSLがこの象限に踏み込むとき、5DSLは構造的な類似(analogy)であって直接の先例(precedent)ではない。
graph出力DSLで同じことをやるなら、関数値がgraph形状に染み出さない境界設計が追加で必要になる。これが5DSLでは問われなかった論点である。