我们对可证明正确的程序了解什么？

计算机程序的复杂性不断提高，计算机在社会中的地位日益重要，这使我想知道为什么我们仍然不集体使用编程语言，而您必须使用编程语言来正式证明代码可以正常工作。

我相信该术语是“认证编译器”（我在这里找到了它）：一种编译一种编程语言的编译器，在该语言中，不仅必须编写代码，而且还必须声明代码规范并证明代码符合该规范。规范（或使用自动证明者这样做）。

在互联网上搜索时，我仅发现使用非常简单的编程语言的项目或尝试适应现代编程语言的失败项目。这引出我的问题：

是否有任何认证的编译器实现了成熟的编程语言，还是这很难/从理论上讲是不可能的？

此外，我还没有看到任何涉及可证明程序的复杂性类，例如“由图灵机确定的所有语言的类（存在证明该图灵机停止的证据）”，我将其称为$ProvableR$作为模拟到$R$，该组递归语言。

我可以看到学习这样的复杂类的优点：例如，对于$ProvableR$停机问题是可判定的（I甚至猜想$ProvableRE$在明显的方式定义的。将可以决定的最大语言类别）。另外，我怀疑我们是否会排除任何实用的程序：当您无法证明程序终止时，谁会使用该程序？

所以我的第二个问题是：

我们对复杂性类了解多少，这些复杂性类要求其包含的语言具有可证明的某些属性？

“验证编译器”通常意味着略有不同：它意味着您有一个编译器，可以证明它发出的机器代码正确地实现了高级语义。也就是说，这证明没有编译器错误。人们提供给编译器的程序仍然可能是错误的，但是编译器将生成错误程序的正确机器代码版本。这些方面最大的成功案例是经过CompCert验证的编译器，它是适用于大部分C语言的编译器。

Compcert编译器本身是具有正确性证明的程序（在Coq中完成），该程序保证如果它为程序生成代码，则将是正确的（关于CompCert设计人员使用的Assembly＆C的操作语义）。用机器检查这些东西的工作量很大。通常，正确性证明的大小是您要验证的程序大小的1倍至100倍。编写经过机器检查的程序和证明是您必须学习的一项新技能，尽管这取决于能否同时做到这点，但这不是像平常一样的数学或编程。感觉就像是您从头开始，就像再次成为新手程序员一样。

但是，对此没有特殊的理论障碍。遵循这些原则的唯一事情是Blum Size定理，对于所有程序全部使用的语言，您都可以找到一种通用递归语言的程序，当使用全部语言进行编程时，该递归语言至少会成倍增大。理解这种结果的方式是，总语言不仅编码程序，而且编码终止证明。因此，您可以拥有带有长期终止证明的简短程序。但是，实际上这并不重要，因为我们只会编写带有可管理终止证明的程序。

编辑：戴乐要求对最后一点做一些阐述。

这主要是一个务实的主张，基于这样一个事实，即如果您可以理解某个程序为什么运行，那么该原因不太可能是数百万个页面的巨大不变性。（我使用的最长不变式只有几页，而且男孩确实会使审阅者发牢骚！这也是可以理解的，因为不变式是程序除去所有有助于人们理解的叙述的原因。）

但是也有一些理论上的原因。基本上，我们不知道有多少方法可以系统地发明其正确性证明很长的程序。主要方法是（1）采取证明正确性的逻辑；（2）找到无法在该逻辑中直接表示的属性（一致性证明是典型的来源）；以及（3）找到一个程序，该程序的正确性正确性证明依赖于不可表达财产的一系列可表达后果。因为（2）是不可表达的，所以这意味着每个可表示结果的证明都必须独立完成，这使您无法确定正确性证明的大小。作为一个简单的示例，请注意，在具有父关系的一阶逻辑中，您不能表达祖先关系。$k$$k$）是可表示的，对于每个固定。因此，通过提供一个程序来使用某个祖先的属性达到某个深度（例如100），可以在FOL中强制正确性证明将这些属性的证明包含一百倍。$k$

关于这一主题的复杂论述被称为“逆数学”，是需要证明一定定理的公理的研究。我对此了解不多，但是如果您向CS提出有关其应用的问题，我敢肯定，至少Timothy Chow，也许还有其他几个人，将能够告诉您一些有趣的事情。

我认为第一个问题的答案是，使用当前工具通常工作量过多。为了获得这种感觉，我建议尝试证明Coq中冒泡排序的正确性（或者，如果您希望挑战更多，请使用快速排序）。我认为期望程序员编写经过验证的程序是不合理的，只要证明这种基本算法的正确性既困难又费时。

这个问题类似于询问数学家为什么不编写可被证明检查者验证的形式证明吗？用正式的正确性证明编写程序意味着证明有关所编写代码的数学定理，并且对该问题的答案也适用于您的问题。

这并不意味着没有成功的经过验证的程序案例。我知道，有团体谁被证明的类似系统的正确性微软的虚拟机管理程序。一个相关的案例是Microsoft的经过验证的C编译器。但总的来说，当前的工具需要大量的开发工作（包括SE和HCI方面），才能对通用程序员（和数学家）有用。

关于Neel关于仅具有全部功能的语言的程序大小增长的答案的最后一段，实际上很容易证明更多（如果我理解正确的话）。可以合理地预期，任何编程语言的语法都将是ce，而不是全部可计算函数的集合，因此对于所有程序全部为总的任何编程语言来说，总共有可计算函数，任何程序都无法计算（任何大小的语言）。

$AC^0$$AC^0$-复杂度类完整，因此它包含了复杂度类中的所有问题并可以证明这些程序的整体性。在证明复杂性方面研究了证明与复杂性理论之间的关系，如果您有兴趣，请参阅SA Cook和P. Nguyen的最新著作“ 证明复杂性的逻辑基础 ”。（提供了 2008年的草案。）因此，基本答案是对于许多类“ Provably C = C”。

$PA$$\epsilon_0$$T$$PA^2$$F$$I\Sigma_1$

但是在我看来，这在程序验证上下文中没有多大意义，因为还有一些程序在扩展上计算相同的功能，但是我们无法证明这两个程序在计算相同的功能，即，这些程序在扩展上是相等的，但不相同故意地。（这类似于晨星和晚星。）此外，很容易修改给定的可证明的总体程序以得到理论上无法证明其总体的程序。

$P$$n$$n$$P$证明中的因式分解算法。（也有研究人员尝试使第一种方法尽可能自动化，但是检查程序有趣的非平凡属性在计算上是困难的，并且如果没有错误的肯定和否定，就无法完全验证。）

您在第一个问题中提出的问题有时被称为“验证编译器”，几年前，Tony Hoare将其提供为计算研究的巨大挑战。在某种程度上，这已经存在并且在诸如Coq定理证明器之类的工具中得到了积极使用，这些工​​具通过类型理论和按类型命题原理（“ Curry-Howard ”）来组织问题。

编辑：只是想在“一定程度上”增加重点。这远未解决问题，但Coq的成功使人们希望这不是一个空想。

检查程序是否正确的工具有时称为程序验证器。在这种情况下，“正确”通常意味着两件事：该程序从不产生某些输出（认为分段错误，NullPointerException等），并且该程序符合规范。

该代码和规范可能会达成共识，但仍然被认为是错误的。从某种意义上说，要求开发人员编写规格就像要求两个开发人员解决问题一样。如果两个实现都同意，那么您将更有把握地确定它们是可以的。但是，从另一个意义上讲，规范比第二种实现要好。由于该规范不需要高效甚至可执行，因此它可能更加简洁，因此更容易出错。

考虑到这些警告，建议您查看Spec＃程序验证程序。

在一般情况下，不可能创建一种算法来确认算法是否等同于规范。这是一个非正式的证明：

几乎所有的编程语言都是图灵完备的。因此，由TM决定的任何语言也可以由以此语言编写的程序来决定。

$Equivalence/TM$

$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$也不能接受。因此，无论两台计算机是否等效，您都可以使用一种算法，但是不能确定它们是否等效，或者您没有给算法足够的时间。

但是，这仅适用于一般情况。您可以通过解决更为宽松的问题来决定规格是否等于程序。例如，您可能只检查了许多输入，或者说这两个程序是等效的，但存在一些不确定性。这就是软件测试的全部内容。

至于其余的问题：

注意：此部分已经过编辑以澄清。事实证明，我犯了我想避免的错误，对不起。

$TrueR$$TrueR \subseteq R$

$ProvableR = TrueR$$ProvableR \subset TrueR$$TrueR \subset ProvableR$$A \epsilon TrueR$$A$$A$$A \epsilon ProvableR$

非正式地，可以将其概括为：在证明一种语言之前，您不知道该语言是可以决定的。因此，如果在正式系统中您知道一种语言是可决定的，则该知识也可以用作证明。因此，您不能同时拥有一种语言既可确定又无法被证明的知识，因此这两个语句是互斥的。

$R$$ProvableR$$ProvableR \subset R$$R$

@Kaveh最好地总结了这一点：可证明的总是在某些系统/理论中可证明的，并且通常与真理不符。

其他复杂性类别也是如此：要确定成员资格，您首先需要证明。这就是为什么我认为您的第二个问题过于笼统，因为它不仅包含复杂性理论，而且还包含计算理论，具体取决于您希望语言所具有的属性。

以下经典专着几乎完全是您的第二个问题：

Hartmanis，J. 可行的计算和可证明的复杂性，CBMS-NSF应用数学区域会议系列，30.工业和应用数学协会（SIAM），宾夕法尼亚州费城，1978年。

$\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$$M_i$$T_i(n)$$M_i$$n$

$T(n) \geq n \log(n)$$g(n) \geq 1$$F$$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$

定理6.5：存在可计算的单调递增的时界，其中 -。F T I M E [ T （n ）] ≠ T I M E [ T （n ）$T(n)$$F$$TIME[T(n)] \neq TIME[T(n)]$

$T(n) \geq n \log(n)$$TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$

但是，对于太空，情况可以得到更好的控制：

$s(n) \geq n$$SPACE[s(n)] = F$$SPACE[s(n)]$

$SPACE[S(n)]=F$$SPACE[S(n)]$$S(n) \geq n$$s(n)$$SPACE[S(n)]=SPACE[s(n)]$

这个问题必须正确提出。例如，没有人想知道给定无限内存以及访问它的某种方式（可能是将基地址移动一定数量的操作）后，实际程序是否会完成。图灵定理在任何具体意义上都与程序正确性无关，并且将其视为程序验证障碍的人们正在混淆两个截然不同的事物。当工程师/程序员谈论程序的正确性时，他们想知道有限的属性。对于对某些事物是否可证明感兴趣的数学家来说，这也是正确的。戈德尔的来信http://vyodaiken.com/2009/08/28/godels-lost-letter/对此进行了详细解释。

即，这显然意味着，尽管Entscheidungsproblem问题的不确定性，数学家有关是或否问题的脑力劳动仍可以完全由机器代替。毕竟，仅需选择如此大的自然数，以至于当机器无法提供结果时，多考虑问题就没有意义了。

检查在实际计算机上执行的程序的巨大状态集并检测不良状态可能是不可行的，没有理论上的理由无法做到这一点。实际上，该领域已经取得了很大进展-例如，请参见http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf（感谢Neil Immerman的贡献）告诉我这件事

一个不同且更困难的问题是确切指定一个人想要一个程序具有正确的属性。