GHC的非懒惰分支

Question

我听说有一个GHC的分支默认编译为严格的代码,而懒惰可以通过注释启用.(IIRC,他说一家金融公司开发分支并将其用于生产代码.)这是真的吗？我找不到它.

该人士还认为,严格评估比懒惰评估(默认情况下)更实用的观点越来越受到人们的认可.我没有在Haskell邮件列表中找到这个确认,但也许这是因为那里的人不是那种以实践为导向的？

所有我觉得严格的Haskell就像明确的东西$!和rnf.虽然我发现惰性评估非常优雅,但我想在Haskell中开发一个程序,我希望避免空间泄漏,并希望获得可预测的性能.

免责声明:我不是要严格要求,我只想看看严格的Haskell或类似的东西.

Answer 1

你在寻找门徒.

因此在Haskell中有两种懒惰可以区分.有懒惰的I/O,这是一个令人厌恶的,并由iteratee库解决(无耻插件:包括我的管道库).然后在纯计算中存在懒惰,这仍然有待讨论,但我会尝试总结懒惰的关键优势,因为你已经熟悉了它的缺点:

懒惰更有效率

一个简单的例子是:

any = foldr (||) False

any查找列表中是否有任何值True.这仅评估第一个元素True,因此列表非常长并不重要.

懒惰只计算它必须计算的数量,这意味着如果将两个惰性计算链接在一起,它实际上可以提高结果计算的时间复杂度. 此Stack Overflow注释提供了另一个很好的例子.

这实际上与iteratee库非常节省资源的原因相同.他们只需要完成与生成结果一样多的工作,这样就可以使用非常容易使用的语义,从而实现非常高效的内存和磁盘使用.

懒惰本质上更具有可组合性

这对于使用严格和函数语言进行编程的人来说是众所周知的,但实际上我在无意中证明了在使用pipes库时有限的证据,其中惰性版本是允许Category实例的唯一版本.管道实际上可以在任何monad中工作,包括纯Identitymonad,所以我的证明也转换为纯代码.

这就是为什么我认为一般的懒惰确实是编程的未来的真正原因,但是我仍然认为Haskell是否实现了"正确"的懒惰是一个悬而未决的问题.

Answer 2

听起来您好像听说过 Robert Ennals关于GHC推测性评估的博士论文。他创建了 GHC 的一个分支，称为“spec_eval”分支，其中进行了推测评估。因为 Haskell 是非严格的而不是明确的懒惰，所以 spec_eval是严格的，直到它实际上有所作为。虽然它在所有情况下都更快，但它需要对 GHC 进行大量更改并且从未被合并。

这个问题之前已经在这个网站上得到了回答。