类型检查器的正确性证明实际上应该证明什么？

我已经进行了几年编程，但是对理论CS并不熟悉。我最近一直在尝试学习编程语言，并且其中的一部分是类型检查和推断。

我的问题是，如果我尝试为一种编程语言编写类型推断和检查程序，并且希望证明我的类型检查器可以工作，那么我要寻找的证明到底是什么？

用通俗易懂的语言，我希望类型检查器能够识别出在运行时可能发生的代码中的任何错误。如果我要使用类似Coq的方法来证明我的实现是正确的，那么这种“正确性证明”将试图显示什么？

这个问题可以用两种方式解释：

• 该实现是否实现了给定的键入系统？$T$
• 打字系统是否确实可以防止您认为应该的错误？$T$

前者确实是程序验证中的一个问题，与键入无关。只需显示您的实现符合其规范，请参阅Andrej的答案。

让我谈谈后面的问题。正如安德烈（Andrej）所说，从抽象的角度来看，键入系统似乎在程序上强制执行属性。实际上，您的键入系统试图防止发生错误，这意味着可键入程序不应表现出感兴趣的错误类别。为了表明做了您认为应该做的事情，您必须做两件事。$T$$T$

• 首先，您正式定义程序立即输入错误的含义 。可以通过多种方式定义它-由您决定。通常，我们要阻止类似的程序 2 + "hello"。换句话说，您需要定义一个程序子集，将它们称为 Bad，它完全包含具有立即输入错误的程序。

• 然后，您必须证明可打字的程序永远不会演变成Bad程序。让我们对此进行形式化。让您的打字判断为 回想一下，应将其读取为：程序 类型为，假定自由变量的类型由环境。那么您要证明的定理是：$\Gamma \vdash M : \alpha.$$M$$\alpha$$\Gamma$

  定理。每当和然后 Bad。$\Gamma \vdash M : \alpha$$M \rightarrow \cdots \rightarrow N$$N \notin$

  如何证明该定理取决于语言的细节，键入系统以及您对Bad的选择。

定义Bad的一种标准方法是说：术语如果既不是值也不是归约步骤，则具有立即类型错误。（在这种情况下，通常称为“ 卡住”。）这仅适用于小步操作语义。证明定理的一种标准方法是证明$M$$M \rightarrow N$$M$

• $\Gamma \vdash M : \alpha$和一起表示。这称为“主体减少”。通常通过同时归纳打字判断的推导和减少的时间来证明。$M \rightarrow N$$\Gamma \vdash N : \alpha$

• 每当 然后不坏。通常也可以通过归纳打字判断来证明这一点。$\Gamma \vdash M : \alpha$$M$

请注意，并非所有键入系统都具有“主题缩减”功能，例如会话类型。在这种情况下，需要更复杂的证明技术。

这是个好问题！它询问我们对键入语言中的类型的期望。

首先请注意，我们可以使用unitype键入任何编程语言：只需说一个字母U，然后说每个程序都具有type即可U。这不是非常有用，但是很有意义。

有很多理解类型的方法，但是从程序员的角度来看，我认为以下内容很有用。将类型视为规范或保证。说具有类型就是说“我们保证/期望/要求满足由编码的属性”。通常，就像一样简单，在这种情况下，属性只是“它是整数”。$e$$A$$e$$A$$A$int

您的类型的表达能力没有止境。原则上，它们可以是任何种类的逻辑语句，也可以使用类别理论和诸如此类的东西。例如，从属类型将使您可以表达诸如“此函数将列表映射到列表以使输出为排序的输入”之类的内容。您可以走得更远，此刻，我正在听有关“并行分离逻辑”的演讲，该演讲使您可以谈论并发程序如何在共享状态下工作。花哨的东西。

编程语言设计中的类型艺术是表达性和简单性之间的一种平衡：

• 更具表现力的类型使我们能够（对自己和对编译器）更详细地解释应该发生的情况
• 简单类型更易于理解，并且可以在编译器中更轻松地实现自动化。（人们提出的类型本质上需要证明助手和用户输入来进行类型检查。）

不应低估简单性，因为并非每个程序员都拥有编程语言理论的博士学位。

因此，让我们回到您的问题：您怎么知道您的类型系统是好的？好吧，证明定理可以证明您的类型是平衡的。有两种定理：

1. 定理说你的类型是有用的。知道程序具有类型应该暗示一些保证，例如，程序不会卡住（这将是安全性定理）。另一类定理会将类型与语义模型联系起来，以便我们可以开始使用实数数学来证明有关程序的信息（这些将是适当性定理，以及许多其他定理）。上面的单型不好，因为它没有这么有用的定理。

2. 定理说你的类型很简单。一个基本的判断是，给定表达式是否具有给定类型是可以确定的。另一个简单功能是提供一种推断类型的算法。关于简单性的其他定理是：表达式最多具有一种类型，或者表达式具有主体类型（即，它具有的所有类型中的“最佳”类型）。

由于类型是非常通用的机制，因此很难更具体。但是，我希望您能看到应该射击的东西。像编程语言设计的大多数方面一样，也没有绝对的成功衡量标准。取而代之的是存在设计可能性的空间，而重要的是要了解您在空间中或想要在空间中的位置。

“证明我的类型检查器可以工作”可能意味着几件不同的事情。我想这是您的问题要问的一部分;）

这个问题的一半证明您的类型论足以证明语言的任何特性。Andrej的答案非常适合imo。问题的另一半是-假设语言及其类型系统已经固定-您如何证明您的特定类型检查器确实正确地实现了类型系统？我可以看到这里有两个主要观点。

一种是：我们怎么能相信某个特定的实现符合其规范？根据所需的保证程度，您可能对大型测试套件感到满意，或者可能需要某种形式的正式验证，或者更可能是两者的混合。这种观点的好处在于，它确实突出了为正在提出的主张设置界限的重要性：“正确”的确切含义是什么？检查代码的哪一部分，而假定正确的TCB是哪一部分？不利的一面是，对这一问题进行过认真的思考会导致一个哲学上的兔子洞倒下 -好吧，如果您不喜欢那些兔子洞，那就是“缺点”。

第二个观点是对正确性的更数学的认识。在数学中处理语言时，我们经常为“理论”建立“模型”（反之亦然），然后尝试证明：（a）我们在模型中可以做的理论中可以做的一切，以及（b）我们在模型中可以做的一切，在理论上可以做的。（这些是健全性和完整性定理。哪一个取决于您是从语法理论还是从语义模型“开始”。）使用这种思维方式，我们可以将类型检查实现视为所讨论类型理论的特定模型。因此，您想证明实现可以做什么和理论上应该做到的之间是双向的。这种观点的好处在于，它的重点实际上在于您是否涵盖了所有极端情况，在不遗漏任何应接受为类型安全的程序的意义上实现是否完整以及实现是否合理。不要让任何程序接受它的错误类型的感觉。缺点是您的对应关系证明很可能与实现本身完全分离，