一键导入
isabelle-record
How to read constants and theorems generated by Isabelle record definitions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
How to read constants and theorems generated by Isabelle record definitions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Operational pipeline to start, monitor, STOP, and recover the MathBench missing-lemma loop running in multi-node fleet mode on the MBZUAI cluster (watcher + slurmx fleet REPLs + login-node RPC host + serial adjudication + phase-2 import reconciliation). Use when launching/resuming the fleet run, stopping it cleanly, recovering after a crash, or applying the hard-won operational rules (correct kill sequence, git safety on the shared checkout, shell/conda/timeout fixes, re-collection prerequisite). For the single-machine AoA×PutnamBench eval use `aoa-putnam-eval` instead; for the design rationale of the loop see `MISSING_LEMMA_LOOP.md`.
How to refresh the local semantic embedding database (~1.5 GB of LMDB at ~/.cache/Isabelle_Semantic_Embedding). The development channel is the Hugging Face Hub tarball via manage_data.py (get/update). End users instead pull it anonymously from Cloudflare R2 with `semantics_manage.py pull`. Use when setting up or refreshing the semantic DB on a machine, or when deformalizations / vector stores are stale or missing. Do NOT run R2 `push` — it overwrites the shared remote and is a human-only action.
How to repackage/upload and download/unpack the Isabelle + paired AFP distribution, published together as contrib/Isabelle2025-2_and_afp-2026-05-13.tar.zst on the Hugging Face Hub (via manage_data.py update/get). Use when publishing a rebuilt Isabelle+AFP tarball (after isabelle scala_build, patches, etc.) or installing/refreshing the distribution on another machine.
How to read Isabelle introduction and elimination rules
Playbook for adding a new import to MathBench_ProverBase and reconciling any syntax conflicts (constant/type short-name resolution and notation) so that PutnamBench problems still parse to identical goal terms. Use when adding/changing imports of the MathBench_Prover session, or when investigating MathBench-vs-PutnamBench environment divergences.
How to read constants and theorems generated by Isabelle datatype and codatatype definitions
| name | isabelle-record |
| description | How to read constants and theorems generated by Isabelle record definitions |
A record defines a named product type with named fields, selectors, updaters, and an extensible inheritance mechanism.
record point = xcoord :: nat ycoord :: natNotation ⦇ xcoord = 3, ycoord = 5 ⦈ (written (| xcoord = 3, ycoord = 5 |) in ASCII) is a record literal — it constructs a point with the given field values.
xcoord, ycoord — selectors (field accessors). xcoord ⦇ xcoord = 3, ycoord = 5 ⦈ = 3xcoord_update, ycoord_update — functional field updaters.
xcoord_update f r returns a copy of r with the xcoord field replaced by f (xcoord r).
Note: r ⦇ xcoord := 10 ⦈ is sugar for xcoord_update (λ_. 10) r.point.make — record constructor. point.make x y = ⦇ xcoord = x, ycoord = y ⦈point.cases:
(⋀xcoord ycoord. r = ⦇ xcoord = xcoord, ycoord = ycoord ⦈ ⟹ P) ⟹ P
→ For any point, there exist field values xcoord and ycoord such that the record is constructed from them (case analysis).
point.induct:
(⋀xcoord ycoord. P ⦇ xcoord = xcoord, ycoord = ycoord ⦈) ⟹ P r
→ To prove a property for all point records, it suffices to prove it for records constructed from arbitrary field values.
point.splits:
Elimination of quantifiers over records:
(∀r. P r) = (∀xcoord ycoord. P ⦇ xcoord = xcoord, ycoord = ycoord ⦈)
→ A universal statement over all records can be replaced by a universal statement over all field values, which is useful to destruct a universally quantified record variable.
Example:
record point = xcoord :: nat ycoord :: nat
record cpoint = point + color :: string
cpoint extends point: it has all parent fields (xcoord, ycoord) plus its own (color).
Inheritance works through a polymorphic extension slot called more, appended after the declared fields. A child record fills the parent's more slot with its own fields. Every record generates three types:
'm point_ext — a type that packages the fields together with a polymorphic more slot: 'm point_ext = ⦇ xcoord :: nat, ycoord :: nat, … :: 'm ⦈.
'm point_scheme abbreviates 'm point_ext
point abbreviates unit point_ext — the concrete closed type, with more fixed to unit.
'm cpoint_ext holds only the new field: 'm cpoint_ext = ⦇ color :: string, … :: 'm ⦈.
'm cpoint_scheme abbreviates ('m cpoint_ext) point_ext — the full chain: xcoord, ycoord from point_ext, then color + open more from cpoint_ext, so cpoint can itself be further extended.
cpoint abbreviates (unit cpoint_ext) point_ext — the closed version.
Parent selectors work on child records: xcoord can be applied to a cpoint because the types are compatible through the scheme mechanism.
cpoint.make :: nat ⇒ nat ⇒ string ⇒ cpoint — construct from all fields (parent + own). cpoint.make x y c builds a cpoint with xcoord = x, ycoord = y, color = ccpoint.fields :: string ⇒ unit cpoint_ext — the extension fragment that cpoint adds on top of point, packaging only the fields declared by cpoint itself (here just color), excluding inherited fields.cpoint.extend :: cpoint ⇒ 'm ⇒ 'm cpoint_scheme — extend a cpoint with additional data via the more slotcpoint.truncate :: 'm cpoint_scheme ⇒ cpoint — strip the extension, closing the more slot with unit to yield a plain cpointcpoint.more :: 'm cpoint_scheme ⇒ 'm — access the extension slot (the polymorphic "rest" of the record)cpoint.more_update :: ('m ⇒ 'm) ⇒ 'm cpoint_scheme ⇒ 'm cpoint_scheme — apply a function to the extension slot