38、面向文档的证明助手：Isabelle 与形式化证明脚本重构探索

面向文档的证明助手：Isabelle 与形式化证明脚本重构探索

1. Isabelle 数据视图与打印机制

在 Isabelle 中，数据视图本质上是部分的，可能会出现动态类型不匹配的情况，这往往暗示着证明器协议基础设施存在故障。为了减少编程错误，用户代码通常会在 ML 中使用静态类型的 Markup.proof_state ，在 Scala 中使用 Proof_State.unapply 。

证明助手主要处理符号术语结构，最终通过美化打印将其展示给用户。这通常采用 Oppen 提出的美化打印变体方法，将文本原子和潜在换行符排列成嵌套块（可选择缩进），生成的美化树可根据给定边距进行格式化，美化打印算法会按需插入空格和换行符。

为了适应面向文档的架构，初始的换行和块指示所构成的物理标记语言可进行如下增强：
1. 逻辑标记添加 ：美化块还可携带逻辑标记。Isabelle/ML 函数 Pretty.markup: Markup.T -> Pretty.T list -> Pretty.T 可将标记信息插入美化树，类似于之前在纯文本上使用的 Markup.markup 。
2. ML 中的符号化格式 ：在 ML 中，美化格式变为符号化。原本的物理布局信息会分别转换为 XML 标记元素 <break width="N"/> 和 <block indent="N">...</block> ，再结合逻辑标记构成 XML 文档，并通过 YXML 编码嵌入证明器输出中。
3. Scala 中的直接格式化 ：在 Scala 中，直接对 XML 树进行物理格式化。换行和块标记元素会展开，在正文文本中生成适当的空格和换行符，剩余的 XML 树仅包含逻辑标记。格式化算法紧密模仿之前的 ML 实现，使用类型化视图 Break(width) 和 Block(indent, body) 识别原始 XML 树中的符号换行和块。
4. 最终渲染 ：最终渲染通过 XHTML/CSS 实现，例如使用基于 JVM 的 Lobo/Cobra 网络浏览器。标记元素 <foo>...</foo> 会转换为 <span class="foo">...</span> （忽略属性），然后与 XHTML 头部和证明器特定的样式表一起提供给浏览器。XHTML 文本会被视为预格式化文本，以保留之前进行的缩进和换行。

目前，Isabelle 仅使用这种 XHTML 渲染方案对打印术语中的某些实体进行传统高亮显示，如全局变量为蓝色、局部变量为棕色、绑定变量为绿色、未声明变量背景为黄色。实际上，利用 XHTML/CSS 的全部潜力可以实现更多功能，如使用盒子和表格布局。由于网络浏览器允许将程序代码附加到 HTML 元素上（可以是 JavaScript 或 Scala 生成的 JVM 代码），我们可以解释某些证明器标记来折叠/展开子术语，或生成弹出窗口显示该点形式实体的相关信息（定义位置、文档等）。此外，使用 HTML 输入表单，还能支持基于证明器输出的简单交互方案，即证明助手提供一些模板，用户可以完成并插入到源文本中。

2. 文档重构

借助文本标记和内容基础设施，我们可以更深入地研究证明器的语义信息。传统的命令行证明器仅以消息形式输出，而在面向文档的环境中，我们可以通过标记将有价值的信息附加到输入上。

从概念上讲，源文件定义了文本的真实含义。证明器通过处理源文件逐步探索其含义，以某种内部配置表示。这些语义信息的某些方面可以附加到原始源文件上，帮助用户理解文本，或支持对文本进行系统操作的工具（如“重构”）。这意味着将证明器的真实语义内容近似重构为外部可读的文档。证明器作为唯一能够真正分析形式文本的实例，可以揭示其内容的重要方面，而无需前端模仿证明器的大部分功能。

然而，证明器语法存在固有的复杂性。为形式语言的源文件提供丰富的语义注释并非新鲜事，例如 Java 的 IDE 能够理解语言的语法和静态语义（包括标识符的作用域和类型信息），以支持对程序文本的系统重构。Eclipse 等框架也为用户自定义语言提供了强大的库（如 Xtext）来实现此类功能。但对于常见的证明助手而言，类似的功能几乎无法实现。除了一些词法分析和表面解析外，在内部生成完全类型化的 λ 项之前，还存在许多语法层。其中一些阶段是明确定义的，如 Isabelle 中基于类型类的有序排序代数的 Hindley - Milner 类型推断；而其他阶段则是开放式的，提供了计算完整的插件机制，例如最近的 Isabelle 允许在用户空间基于任意 ML 代码重新定义类型规则。同样，在输出 λ 项直到最终生成可打印文本的过程中也存在类似情况。这些机制都可能依赖于形式语言作用域规则下的局部声明。

以下是 Isabelle/Isar 中的一个简单示例，展示了局部混合中缀声明如何修改证明块内的符号表示：

notepad
begin
    fix foo :: ′a ⇒′a ⇒′a
    fix bar :: ′a ⇒′a ⇒′a
    { write foo (infix · 70) have x · x = foo x x .. }
    { write bar (infix · 70) have x · x = bar x x .. }
end

此外，Isabelle 允许通过态射转换任意声明，在不同的形式上下文之间进行转换。因此，任何试图直接分析文本的证明器 IDE 或理论浏览器都注定会失败。类似的情况也出现在 Coq 中，例如曾有通过“指向证明”进行直接结构操作的方法，但随着证明器的发展，这些方法所依赖的 Coq 语法树内容假设被打破，最终导致 PCoq 前端崩溃。

标准 IDE 语法插件的开发者可能会要求证明器限制为可判定语法，或提供包含完整信息的抽象语法树，但这是不现实的。因为现有的具有复杂符号表示的理论库可能需要缩减或停用，而且当前的证明器（如 Coq 或 Isabelle）尚未完全处理数学符号的复杂性，并且趋势是使用更复杂的符号表示，如 Matita 所示。

问题在于如何在证明器复杂的语法层中传递语义信息，避免对证明器语法树做出强假设，并认识到证明器只能提供部分重要信息。解决方案是仔细检查像 Isabelle 这样复杂证明器的语法层次结构，得出以下结论：
1. 文本位置可观测 ：纯文本可被外部工具清晰观测，证明器可以与前端就文本位置的精确寻址达成一致。
2. 命令视为事务 ：理论和证明语言的主要元素（在 Isabelle 术语中称为“命令”）可视为事务，它们定义了对内部状态的明确更新。假设事务执行是线性的（内部状态信息单调增加且无回溯），我们可以将其跟踪信息作为结果的一部分收集起来。
3. 标记树的组装 ：跟踪信息可以组装成一个外部标记树，与事务上下文中的原始文本关联。

标记报告扩展了向用户打印文本消息的概念。Isabelle/ML 的错误、警告等消息通道通过 Position.report: Position.T -> Markup.T -> unit 进行扩展，用于维护当前事务的隐式标记树。证明器只需将精确的位置信息传递到发现某些形式内容的点，并将外部化版本报告回源文件。这意味着在某些输入阶段只传递较少的信息。

有了这种概念上的简化，我们需要重新设计一些核心的证明器语法模块，以提供有用的报告。在某些阶段可能需要额外的技巧来保留精确的位置信息，例如在 Isabelle 中从引用的“外部语法”转换到“内部语法”时，我们会重新使用古老的 ASCII DEL 字符（127）进行填充。在 Isabelle 中，语法阶段大约有 12 个，对于术语和类型的内部语法，包括一些计算完整的机制，如所谓的“翻译函数”，用于实现派生绑定器或隐式状态依赖（如 Hoare 逻辑符号）。常规的类型检查阶段也有自己的插件概念，通常包括 Hindley - Milner 类型推断的扩展，如“类型改进”和可选的“强制函数”。期望将完全注释的语法树通过所有这些阶段是不现实的，但按照上述方案进行位置报告在对现有代码库进行一些小的修改后是可行的。

Isabelle2011 已经报告了其“外部语法”的标记信息，包括标记和命令跨度，以及各种可直接访问的绑定位置。而类型和术语的“内部语法”更为复杂，标记、原始解析树、自由变量与绑定变量的作用域等信息已经可以用于报告，但类型信息和子表达式标记仍然缺失。对于非平凡术语注释的关键思想（在官方 Isabelle2011 之后的 Isabelle 仓库版本中部分实现）是将原始术语语言中的源位置伪装成类型约束，然后通过主要的语法翻译层（其中存在许多用户定义的转换），直到进行 Hindley - Milner 类型推断的点。根据传统的带有可选类型约束的 lambda 演算结构，旧的语法操作应该能够处理这些额外的注释，但实际上可能需要修复用户代码中的一些遗漏。

使用的 Poly/ML 5.4 编译器（由 David Matthews 开发）也会生成关于标准 ML 静态分析结果的重要报告。例如，在 Isabelle/Isar 中的以下 ML 代码片段：

ML ⟨⟨
fun foo th = Thm.prems_of (th RS @{thm refl})
⟩⟩

使用 Isabelle2011 的实验性 Isabelle/jEdit 证明器 IDE 处理这些源文件时，文档标记会以盒装子表达式、推断类型的工具提示和引用标识符的超链接（如局部的 th 和 Isabelle/ML 库中的全局 RS 运算符）的形式呈现。标记等的语法高亮显示也基于 Isabelle 的精确语义信息，编辑器只需从通用文档标记树中获取这些信息。此外，还有更多的可能性，例如通过同时高亮显示绑定和引用位置来指示变量作用域（就像常见的 IDE 那样），或弹出菜单指向解释引用概念的其他形式文档（Isabelle 手册已经提供了合适的形式标记）。

面向文档的证明助手：Isabelle 与形式化证明脚本重构探索

3. 形式化证明脚本重构

随着技术的成熟，定理证明在大规模场景中的应用越来越普遍，无论是工业界还是学术界都有许多大型的形式化项目。例如，在验证领域有 IP 栈的规范和微内核的功能正确性验证；在形式化数学领域，Gonthier 完成了四色定理的形式化证明，Hales 正在进行开普勒猜想的形式化证明。这些完成的证明脚本长度从约 10,000 行到 200,000 行不等，每个脚本都证明了数百或数千个引理，代表了数年的人力投入。

然而，大规模的形式化证明开发并非易事。编写证明往往比编写程序更具挑战性，因为形式化证明更加复杂、密集且相互依赖。但目前证明开发所使用的工具却十分原始，大多只是基本的文本编辑器，缺乏用于快速构建、轻松修改或浏览的高级手段。这也是交互式证明器未能广泛应用的主要原因，使得学习和使用它们变得异常繁琐。

与之形成鲜明对比的是，现代软件工程（SE）工具为大型程序的维护提供了良好的支持。其中，重构是一项重要的 SE 技术，它是一种保持代码语义不变的转换，旨在改进代码的设计、结构或可读性。重构可以是广泛而常规的操作，理想情况下由工具辅助完成，即通过算法检查安全前提条件后一次性进行全局更改。许多重构操作虽然简单，但前提条件却很复杂，例如重命名和移动操作。

我们提出将证明脚本重构作为构建、重组和维护形式化证明开发的强大工具。我们认为采用形式化方法至关重要，并通过在我们自己设计的简化证明脚本和声明式证明语言中定义和证明一些有价值的重构的正确性来进行说明。

4. 总结与展望

我们展示了如何在尽量减少对现有代码库改动的情况下，增强传统的证明助手以支持具有丰富语义信息的文本文档。保留了用 ML（或 Haskell）实现的证明器的文化背景，避免了编程风格的过度“XML 化”。此外，JVM 上日益流行的 Scala 语言有助于将证明器的应用范围扩展到更广阔的领域。

这项工作可以看作是早期克服证明助手纯文本处理方式的延续。与以往的方法相比，我们的方法有很大不同。例如，PGIP 要求在没有任何上下文的情况下立即实现“证明脚本解析”，而我们的方法是让证明器在信息可用时逐步报告。

Matita 是一个从一开始就设计了 IDE 支持和高级呈现格式的证明助手，但即使经过大量努力，其前端仍然类似于传统的 Proof General。与之相比，我们的方法是通过最小的努力增强现有证明器，简化与强大前端（如 IDE、浏览器、Web 框架）的连接，尤其是在 JVM 上。而且，我们的带注释证明源文档模型超越了 Matita 的基本 IDE 功能，更注重对输入源的注释。

“XML 化 Mizar”的工作基于可以实现完整 XML 语法树的假设，这与我们所观察到的证明器语法的固有复杂性不同。Mizar 是一种封闭语言，为其工具链定义固定的 XML 格式相对容易，还允许用户使用 XSLT 等实现派生工具。但对于更复杂和开放式的 LCF 家族证明器（如 Isabelle、Coq 和 HOL），这种传统的外部化证明器内容的方法几乎不可行。

Proviola 的目标是从证明运行中提取文档内容，但由于无法访问 Coq 的内部开发，其文档内容仅限于传统的证明状态和消息输出。我们的工作可以看作是在证明器端提供了缺失的环节，它可以简化像 Proviola 这样的项目，并提供更有价值的内容。

最终，只有证明器本身才能从其真实的语义状态中揭示大量的文档内容。我们已经展示了如何以一种深刻的方式实现这一目标，而无需从头重写主要的证明助手。未来，我们希望看到更多的证明助手复用这些概念，更多的前端利用这种面向文档的证明器提供的内容。

以下是一个简单的 mermaid 流程图，展示证明脚本重构的基本流程：

graph LR
    A[开始] --> B[分析证明脚本]
    B --> C{是否满足重构条件}
    C -- 是 --> D[执行重构操作]
    C -- 否 --> B
    D --> E[验证重构结果]
    E --> F{结果是否正确}
    F -- 是 --> G[结束]
    F -- 否 --> B

同时，为了更清晰地对比不同证明助手的特点，我们列出以下表格：
| 证明助手 | 代码库情况 | 前端支持 | 语义信息处理 |
| ---- | ---- | ---- | ---- |
| Isabelle | 有一定历史，需最小改动增强功能 | 可与多种前端连接，如 IDE、浏览器 | 通过标记和重构实现语义信息附加和处理 |
| Matita | 全新设计，有专门的 IDE 支持 | 前端类似传统 Proof General | 注重数学公式输出，对输入源注释较弱 |
| Coq | 复杂且开放式 | 曾有前端因语法树变化而崩溃 | 传统输出方式，语义信息处理能力有限 |