C 标准ML可靠性证明？

关于标准的ML编译器，我的问题是，即使ML本身是正式定义的，使得证明程序的确定性评估成为可能，编译器本身不是用C语言编写的吗？C语言没有正式定义，至少不是全部？我想我的问题是，如果我们用标准的ML编写一个程序，并且可以证明它的正确性，那么我们怎么知道C编写的编译器没有以可能改变结果的方式运行呢

---

谢谢，这是一个责任问题。无论您的SML运行时或编译器使用何种语言编写（SML是一种规范，SML编译器不必使用C代码，它可以是任何其他语言），您的责任是使您的SML程序按照SML规范工作。如果SML编译器有缺陷，那是其他人的问题

您是否考虑过SML运行时的编译指令所运行的处理器？谁正式证明了这一点？那么在处理器晶体管内部运动的电子呢？谁告诉他们按照处理器设计所依据的物理“定律”工作？谁正式证明了这些法律

这不是你的问题

---

也就是说，在编写本文时，有一个C编译器基本上是用Coq编写的。该编译器为输入语言（大多数C语言）和目标汇编语言定义形式语义。只要SML实现在使用这种风格的C编译时能够工作，输入语言就不必完全是C。如果您使用CompCert的输入语言实现SML，请尽可能遵循正式定义，你会有一个SML解释器，它的信任链几乎不间断地向下延伸到汇编程序。

仅仅因为你可以编写糟糕的C程序并不意味着你必须这样做。编写一个正确的C程序并从C语言规范中推断程序正确运行是完全可能的。

我喜欢这个答案，它完全有道理，但我想我的问题是所有运行SML的定理证明软件，这不都取决于它所使用的C编译器的正确性吗？因此，请确保用于证明某些内容的SML在理论上是正确的，但我们依靠C成功编译，这无法证明是正确的。@SJP如果您还没有看到这篇博文，您会喜欢它的：。但无论如何，我们不需要对我们的程序有绝对的信心，因为没有我们有绝对信心的机器来执行它们。在一次计算中，只需要一个阿尔法粒子就可以改变一点。各种形式化的方法都提供了一种自信的方式，比传统的技术更有效。试图使用它们的人看到的问题不是编译器错误导致验证系统不健全的可能性，而是成本问题，这是我们应该关注的第一点注意，大多数ML编译器不是用C编写的，除了运行时系统的一些小部分。它们中的大多数（全部？）实际上是用ML引导的。不过，这是一个好问题。bug可以出现在任何语言的任何地方。如果正式验证器有bug怎么办？如果编译正式验证器的编译器引入了一个bug呢？从数学上很难确定复杂系统的行为。所有这些都是通过易受宇宙射线、制造缺陷和良好的量子不确定性影响的电子设备来实现的。@Potatoswatter：“如果正式验证器有缺陷怎么办？”：这是一个好问题，ant。为了回答这个问题，有些验证器依赖于小型可信任内核（最小、更可信任），比如LCF、Isabelle，和其他一些LCF变体。所有更高级别的证明显然都必须通过这个小内核，决不能绕过它。SML有一个经过正式验证的实现，叫做CakeML，另外，至少有一个经过正式验证的C编译器，它是。