依赖类型的编译器比解释器难吗？

我一直在学习有关实现依赖类型的知识，例如本教程，但其中大多数是实现解释器。我的问题是，为依赖类型实现编译器似乎比编译器难得多，因为您可以真正评估依赖类型参数以进行类型检查。

所以

• 我的天真印象对吗？
• 如果是正确的话，关于实现支持依赖类型的静态检查语言的任何示例/资源？

这是个有趣的问题！正如Anthony的答案所暗示的，只要您已经有一个解释器可以评估类型检查的术语，就可以使用通常的方法来编译非依赖的功能语言。

这是Edwin Brady采取的方法。现在，从概念上讲这更简单，但是在执行类型检查时，它确实失去了编译的速度优势。这已经以几种方式解决。

首先，可以实现一个虚拟机，该虚拟机可以将术语实时编译为字节码以执行转换检查。这就是Benjamin Gregoirevm_compute在Coq中实施的背后思想。显然也有此论文由德克Kleeblatt在这个确切的主题，但是实际下来的机器代码，而不是虚拟机。

其次，可以用一种更常规的语言生成代码，该代码在执行时会检查所有类型转换，以对一个从属类型的程序进行类型检查。这意味着我们可以使用Haskell来对Agda模块进行类型检查。可以编译并运行该代码，如果可以接受，则可以假定依赖类型语言的代码类型正确（除非实现和编译器错误）。我首先听说过Mathieu Boesflug提出的这种方法。

最后，可能需要以各种形式出现的术语和打算运行的术语是两种不同语言的一部分。如果出现在类型级别的术语本身没有从属类型，则可以分两个阶段进行编译：首先，编译“类型级别”代码，然后在检查“术语级别”的类型时可以执行此代码码。我不知道会以这种方式运行的任何系统，但是对于许多系统来说，这都是可能的，例如Microsoft的F$^*$语言具有不同的类型级别和程序级别术语。

Edwin Brady的博士学位论文概述了如何为依赖类型的编程语言构造编译器。我不是专家，但是我想说，这比实现类似于System F的编译器要困难得多。许多原理是非常相似的，而有些是相同的（例如，超级组合器的编译）。本文涵盖了许多其他问题。