有了丰富的可用类型信息，为什么 Haskell 运行时不能避免运行 GC 来清理？应该可以找出所有用法并在编译的代码中插入对 alloc/release 的适当调用，对吧？这将避免运行时 GC 的开销。
最佳答案
询问函数式编程语言是否可以通过跟踪使用情况来减少 GC 是明智的。尽管是否可以安全地丢弃某些数据的一般问题是无法确定的(因为条件分支)，但更努力地静态工作并找到更多直接释放的机会肯定是合理的。
值得关注的是 Martin Hofmann 和 Mobile Resource Guarantees 项目团队的工作，他们将类型导向的内存(de/re)分配作为一个主题。然而，使他们的东西工作的东西是 Haskell 在其类型系统中没有的东西——线性。如果您知道函数的输入数据对其余计算是保密的，您可以重新分配它们占用的内存。 MRG 的东西特别好，因为它管理一种类型的释放和另一种类型的分配之间的实际汇率，这在纯粹的功能性外观下变成了很好的老式指针修改。实际上，使用这些技术可以使许多可爱的简约变异算法(例如指针反转遍历、覆盖尾指针构造等)看起来纯粹是功能性的(并检查讨厌的错误)。
实际上，资源的线性类型为可能有助于减少 GC 的使用分析提供了一种保守但机械可检查的近似值。有趣的问题包括如何将这种处理方式(故意的副词选择)与通常的持久处理巧妙地混合在一起。在我看来，相当多的中间数据结构在递归计算中具有初始单线程阶段，然后在计算完成时被共享或丢弃。有可能减少此类过程产生的垃圾。
TL;DR 有很好的类型化的使用分析方法可以减少 GC，但是 Haskell 刚才有错误的类型信息，对于这个目的特别有用。
关于memory-management - 为什么 Haskell 编译器不促进确定性内存管理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7038811/