为什么GHC在脱毒之前会进行类型检查？

Question

是否有充分的理由首先运行类型检查器？如果它运行在较小的语法上,那么类型检查器似乎会变得非常简单,特别是因为在当前系统中,每个语法扩展都需要触及类型检查器.这个问题尤其适用于箭头语法,这里的评论中所述的类型检查被认为是虚假的.

我想这样做的一个原因是不会发出提及生成代码的错误,但是在deriving条款未能进行类型检查的情况下已经涵盖了这种情况; GHC知道代码是生成的.

Answer 1

在"开源应用程序架构"一书的第 2卷中找到的GHC文章中有一节关于这个问题:

键入检查源语言

一个有趣的设计决策是是否应该在去除之前或之后进行类型检查.权衡取舍如下:

• 在desugaring之前进行类型检查意味着类型检查器必须直接处理Haskell的非常大的语法,因此类型检查器有许多需要考虑的情况.如果我们首先贬低(Core的无类型变体),可能希望类型检查器变得更小.

• 另一方面,在脱贫后进行类型检查会产生一项重要的新义务:这种去除不会影响哪些程序是类型正确的.毕竟,贬低意味着故意丢失信息.可能的情况是,在95%的情况下没有问题,但是这里的任何问题都会迫使Core的设计有所妥协,以保留一些额外的信息.

• 最重要的是,对一个荒谬的程序进行类型检查会使报告与原始程序文本相关的错误变得更加困难,而不是报告其(有时精心设计的)脱落版本.

大多数编译器在desugaring之后键入check,但是对于GHC我们做了相反的选择:我们键入检查完整的原始Haskell语法,然后去掉结果.听起来好像添加一个新的句法结构可能很复杂,但是(在法国学校之后),我们以一种简单易懂的方式构建了类型推理引擎.类型推断分为两部分:

• 约束生成:遍历源语法树,生成类型约束的集合.这一步涉及Haskell的完整语法,但它是非常简单的代码,并且很容易添加新的案例.

• 约束求解:解决聚集的约束.这是类型推理引擎的微妙之处,但它独立于源语言语法,对于更小或更大的语言也是如此.

总的来说,先前的类型检查设计选择已经证明是一个巨大的胜利.是的,它为类型检查器添加了代码行,但它们是简单的行.它避免了为同一数据类型提供两个冲突的角色,并使类型推理引擎不那么复杂,并且更容易修改.此外,GHC的类型错误消息非常好.