浅嵌入与深嵌入

47

在将逻辑编码到诸如Coq或Isabelle的证明助手中时，需要在使用浅埋和深埋之间进行选择。在浅层嵌入中，逻辑公式直接写在定理证明者的逻辑中，而在深层嵌入中，逻辑公式表示为数据类型。

各种方法的优点和局限性是什么？
是否有任何指南可用于确定使用哪个？
是否可以任何系统的方式在两种表示形式之间切换？

作为动机，我想将各种与安全性相关的逻辑编码到Coq中，并想知道不同方法的优缺点。

lo.logic coq proof-assistants

— 戴夫·克拉克
source

28

各种方法的优点和局限性是什么？

深度嵌入的优点：您可以通过对公式结构的归纳来证明和定义事物。利益的例子是公式的大小。
深度嵌入的缺点：您确实可以明确处理变量的绑定。通常这很费力。

是否有任何指南可用于确定使用哪个？

浅层嵌入对于导入对象逻辑中证明的结果非常有用。例如，如果您已经用小逻辑（例如，分离逻辑）证明了某些东西，浅层嵌入可能是将结果导入Coq的选择工具。

另一方面，当您想证明有关对象逻辑的元定理时（例如像切消除），深度嵌入几乎是必不可少的。

是否可以任何系统的方式在两种表示形式之间切换？

浅层嵌入背后的想法实际上是直接在对象公式的模型中工作。通常，人们会直接将对象公式P（使用符号或通过手动翻译）映射到Prop的居民，当然，有些Prop的居民无法通过嵌入对象逻辑的公式来获得。因此，您将失去某种完整性。

因此，可以通过解释函数发送在深度嵌入设置中获得的每个结果。

这是一个小例子：

归纳公式：设置：=
    事实：公式
  | 假：公式
  | 范德：公式->公式->公式
  | 对于：公式->公式->公式。

定点解释（F：公式）：属性：=将F与 
    真=>真
  | 假=>假
  | Fand ab =>（解释a）/ \（解释b）
  | 对于ab =>（解释a）\ /（解释b）
 结束。

归纳导数：公式->道具：= 
    deep_axiom：可派生的Ftrue
  | deep_and：forall ab，可派生a->可派生b->可派生（Fand ab）
  | deep_or1：所有ab，可派生a->可派生（对于ab）
  | deep_or2：所有ab，可导b->可导（对于ab）。

感应式可推导式：道具->道具：= 
    thin_axiom：可衍生True 
  | thin_and：全部ab，可衍生a->可衍生b->可衍生（a / \ b）
  | thin_or1：全部ab，可衍生a->可衍生（a \ / b）
  | 浅色或浅色：全部ab，可衍生b->可衍生（a \ / b）。

（*您可以证明以下引理：*）
引理shallow_deep： 
   全部F，可导F->可导（解释F）。

（*您不能证明以下引理：*）
引理t： 
   forall P，可衍生P->存在F，解释F =P。

— 渣
source

22

粗略地讲，通过深度嵌入逻辑，您（1）定义表示逻辑语法的数据类型，并且（2）给出语法模型，并且（3）证明关于语法的公理相对而言是合理的到模型。通过浅层嵌入，您可以跳过步骤（1）和（2），而仅从模型开始，并证明公式之间的必要性。这意味着浅层嵌入通常不需要那么多的工作，因为浅层嵌入代表了您通常需要深层嵌入完成的工作。

但是，如果进行深度嵌入，通常编写反射式决策过程会更容易，因为您正在使用的公式实际上具有可以重复使用的语法。另外，如果您的模型很奇怪或很复杂，那么通常就不想直接使用语义。（例如，如果您使用双正交性来强制允许闭合，或者使用Kripke样式模型来强制分离逻辑或类似游戏中的框架属性。）但是，深层嵌入几乎肯定会迫使您对变量绑定和替换进行很多思考。，这会令您发怒，因为（a）琐碎的事，（b）永无止境的烦恼之源。

您应该采取的正确顺序是：（1）尝试浅浅嵌入。（2）当这种方法用尽时，请尝试使用策略和报价来运行要运行的决策程序。（3）如果那也没用，请放弃并使用依赖类型的语法进行深度嵌入。

如果这是您第一次来，请计划在（3）上花几个月的时间。你将需要熟悉你的证明助手的花哨的功能，以保持清醒。（但这是一项总的来说会得到回报的投资。）
如果您的证明助理没有依赖类型，请保持级别2。
如果您的目标语言本身是依赖类型的，请保持级别2。

另外，请勿尝试逐渐爬上梯子。当您决定提高复杂性时，一次要走完整的一步。如果您一点一点地做，那么您将获得许多奇怪且无法使用的定理（例如，您将获得多个半确定的语法，以及以奇怪的方式混合语法和语义的定理），您将最终不得不扔出去。

编辑：这是一条评论，解释了为什么逐步走上阶梯是如此诱人，以及为什么（通常）导致苦难。

$A \star B$ $I$ $A \star B \iff B \star A$ $(A \star B) \star C \iff A \star (B \star C)$ $(I \star A) \star (B \star C)$ $A \star (B \star (C \star I))$

$\star$

这是正确的，并且有效！但是，请注意，合取也是ACUI，析取也是如此。因此，在其他证明中，您将经历相同的过程，即使用不同的列表数据类型，然后针对分离逻辑的不同片段使用三种语法，并且每种语法都有一个元定理，这些定理不可避免地会有所不同，并且您会发现自己想要一个证明为分离析取连词而得到的元定理，然后您想要混合语法，然后变得疯狂。

最好以合理的努力来瞄准您可以处理的最大片段，并做到这一点。

— 尼尔·克里希纳斯瓦米（Neel Krishnaswami）
source

尼尔，感谢您的出色回答。我希望我可以接受两个答案（我是根据其他人的投票决定的）。

— 戴夫·克拉克

没问题。我只是想起了我需要添加到此答案中的一些内容，说明为什么逐步进行如此诱人。

— Neel Krishnaswami 2010年

处理ACUI属性始终很麻烦。Coq为什么不能从Maude的书中摘取叶子？

— 戴夫·克拉克

14

重要的是要了解从深到浅的频谱。您对语言的各个部分进行了深层次的建模，这些部分应该以某种方式参与有关其结构的归纳性辩论，而其余部分最好放在逻辑基础的直接语义的浅层之中。

例如，当您想对Hoare Logic进行推理时，可以以较浅的方式对表达式语言进行建模，但是，当时间分配语言的轮廓应该是具体的数据类型。您无需输入x + y或a <b的结构，但需要使用whileetc。

在其他答案中，有对依存类型的暗示。这提醒了一个古老的问题，即以理智的方式用活页夹来表示语言，以使它们尽可能浅，但仍会接受一些归纳论证。我的印象是，陪审团仍在评估过去10到20年间针对该主题提出的所有不同方法和论文。在不同程度上，针对不同证明助手社区的“ POPLmark挑战”也与此有关。

奇怪的是，在没有依赖类型的经典HOL中，C.Urban的HOL-Nominal方法对于浅层绑定非常有效，尽管它没有赶上这些编程语言形式化社区的文化转变。

— 马卡留斯
source