applyはリンカ兼ローダである
applyの仕事をコンパイラの言葉で言うと、リンクとロードである。plan中の穴を実値で埋めながら、依存順に実行していく操作だからである。
plan中のdeferred参照(vpc.vpc_idの穴)は未解決シンボルであり、Unknownはその表示名である。applyは依存DAGの位相順 — リンク順 — にノードを実行し、各ノードの実行が完了するたびに、その出力(プロバイダが採番した実値)で後続ノードの穴を埋める。これは再配置(relocation) — オブジェクトファイル中の「あとで実アドレスを入れる」印に、ロード時に実値を書き込む操作 — の正確な対応物である。シンボルが解決できない構成(相互依存)はリンク不能としてエラーになる(循環依存検出)。
プロバイダはターゲットアーキテクチャである。同じIRがaws / awscc / mockという異なるバックエンドで「実行」でき、mockはエミュレータに当たる。プロバイダがWASMプラグインであることは、バックエンドがプラグイン化されたコンパイラ基盤(LLVMのターゲット追加)に似た構造で、WITプロトコルはそのABIである。
ABIとして読むと、境界での型消去も見慣れた現象になる。プラグイン境界で型情報の一部が不可逆に失われるのは、ABIが表現できる型がソース言語の型より粗いという、コンパイラでは日常的な事態(名前マングリングで失われる情報、C ABIに落ちるときに消えるジェネリクス)に対応する。protocol_versionの照合はABIバージョニングである。
そしてリンカ・ローダとして読むと、すぐに一つの問いが立つ。再配置はIRに新しい値を書き込む操作である以上、「再配置後のオブジェクトを誰かベリファイするのか」という問いが避けられない。