[narumincho]

Requested by ナルミンチョ · project thread

サーバー処理の definy 移行の続き (#816 の次)。SubmitEvent で受け取ったコミットのパーツの中身を求める処理 (定義の式の評価) を、ホストの TypeScript (commitContents) から service.wasm の中の definy に移した。

変更

• definy.resolve-commit-contents: コミットのパーツの中身を求め、definy.check-commit-input に渡す
  1. core.define-part / core.define-type の呼び出しで引数がリテラルのものは評価器を使わずに読む (definy.immediate-part-content。説明・可視性・none / some(quote(e).expression) のリテラルを型の付いた値に読む)
  2. それ以外は、quote の外の参照をたどって外のパーツの式を読み (definy.collect-evaluation-parts → 新しい要求 read_part_definitions)、core.eval-value で評価する
  3. 評価した値 (core.value) は新しい要求 decode_part_contents でホストに core.part-content にしてもらう。求まるものがある間繰り返し (definy.evaluate-pending-definitions)、評価器で求めたパーツは定義の式も型検査する
• read_commit_check_input が返すものを definy.commit-check-source にした (パーツは評価前の定義の式)。ホストは CAS の定義の式が core.expression の形かだけを確かめる
• docs/service.md (「定義の式の評価」を追加)、docs/part-definition.md を更新

そのまま残したもの

• 型環境 (各プロジェクトの main の最新のコミット) の中身を求める評価は、まだ TypeScript (commitContents。結果をキャッシュしている)
• core.value を型の付いた core.expression にする関数が definy にまだ無いので、その変換は decode_part_contents としてホストが行う

挙動の違い

• 評価器が trap する定義 (無限の再帰など) は、そのパーツだけ評価できない扱いではなく SubmitEvent 全体が internal になる
• 参照するパーツが揃っているかを評価前に確かめなくなった (評価器は止まらずに unit になるので、値の形の確認か定義の式の型検査で見つかる)

確認

• npm run lint / npm run check / npm test (586 件) 通過。worker/service_io.test.ts にその場で読む場合と評価器を使う場合のテストを足した
• npx playwright test (E2E 41 件) 通過

---

Generated by Claude Code