IaCではIRダンプが一級の製品機能である
planを中間表現として読んだときの最も特徴的な性質はこれである。このIRはユーザーインターフェースである。
通常のコンパイラ
IRダンプは開発者のデバッグ手段にすぎない。-emit-llvmの出力を毎回人間が読んでから実行を承認する、というワークフローはない。
IaC
「IRを人間がレビューして承認する」ことがワークフローの中核である — planを見てからapplyする。
この違いは投資の配分をそのまま説明する。plan表示・detail level・TUIといった表示系への投資は、装飾ではなくIRのpretty printerが一級の製品機能であることの帰結である。コンパイラの類比で「IRダンプの見やすさに開発リソースを割く」と言えば奇妙に聞こえるが、IRが承認の対象である以上それは中心機能への投資である。
そしてこの読みは、IRの構造的性質に別の意味を与える。IRに継続が残らないこと(planがモノイド的な平らな列であること)は、単に解析しやすいという話ではなく「IRダンプが全情報を含むこと」の保証である。継続がIRの中に隠れていれば、ダンプを読み切っても実行時に何が起きるかは分からない。人間のレビューが意味を持つのは、成果物が平らだからである。
逆に言えば、成果物にプログラム片が残る設計 — デプロイ中に走るコールバックを書ける設計 — では、IRダンプを見せてもそれは近似の提示にとどまる。IRを製品機能に昇格させられるかどうかは、IRの構造そのものが決めている。