编译器在优化阶段所能做的功能之一就是将低效的表示替换为等效的表示。例如,在Haskell中,您可以使用惰性列表来计算数字的总和,但是GHC Haskell编译器将认识到这等效于使用带有临时变量的迭代。这样,您就可以根据易于推理的简单抽象进行编程,而您的可执行文件则利用了更适合硬件平台的表示形式(而在规模上很难进行推理)。
但是,编译器已知的等效项主要限于众所周知和研究的数据结构,例如列表的流融合。您可以在源代码中定义您自己的等效项(使用一对在任一方向上都构成身份的转换函数),但是您必须手动应用它们,选择正确的类型以在所有地方使用都可能很棘手为了避免过多的转化。
现在,让我们想象一个世界,在这里可以定义“更高归纳类型”,例如一个标准的查找图。该类型具有用于各种地图的几个构造函数:二进制搜索,AVL,红黑色,Trie,Patricia等。与典型的数据构造函数一起,您还定义了一个等价类型,该类型捕获这些表示之间可能的多次转换,其中不同转换提供了不同的效率维度(即时间与内存)。
如果编译器能够使用此概念透明地重写映射表示,怎么办,就像今天使用列表融合一样?同时,在您的代码中,您可以使用最简单的推理构造(如果在这样的环境中,可以简化证明工作)。这听起来像是具有多个实现的抽象接口,但是它具有选择任何实现的自由,并使编译器根据需要透明地替换另一个实现,而不会影响程序的含义。
HoTT为我们提供了一种类型理论基础,以证明这种奇特的重写机制和这些定义丰富的类型是正确的,因为它提倡将等效概念等同于相等。这在实践中如何实际发挥还有待观察,但它为我们提供了未来工作的理论框架。