有没有使用严格评估的haskell编译器或预处理器?

如果您有一个使用严格评估的haskell编译器,它不会编译haskell。 懒惰 不严格是haskell规范的一部分!

然而,还有其他选择。

• DDC 试图创建一个显式的懒惰的haskell变体,它支持破坏性的更新,同时保留haskell的所有其他优点。有一个问题:编译器目前只处于“阶段”,尽管它看起来至少是可用的。

• Create a preprocessor, as others have done.

• 学会正确使用haskell__。如果可以将测试用例简化为可公开显示的内容,那么可以将其发布到 Haskell-Café mailing list 在这些问题上,人们对非严格的影响非常有帮助。

我真的不想经常放!S和$!在我的节目里

你做错了,如果这就是你对haskell编程的方式的话:)你根本不需要这么做。使用ghc,使用-o2,适当时使用严格的数据类型,适当时使用惰性数据类型。不要以为懒惰会成为一个问题——它是解决很多问题的方法。

过去曾有两次尝试严格评估哈斯克尔:

• Jan Willem Maessen的 Eager Haskell
• Rob Ennals 博士论文

但他们都专注于坚持haskell的非严格语义,但使用的是最严格的评估策略,而不是真正改变语义,而且都没有真正看到光明的一天。

编辑:Martijn关于严格插件的建议看起来非常适合您的目的,因为它实际上满足了您的需要,并且作者仍然活跃在Haskell社区中,我已经忘记了。

也见 ghc-strict-plugin ,例如 GHC's plugin framework ,描述见 Monad Reader 12 .

我感觉到你的痛苦。我日常编程中最大的pita就是处理这些问题!@#$%^&(空间泄漏。

然而,如果它有帮助,随着时间的推移,你确实学会了如何处理这件事(这是一种艰难的方式),它确实会变得更好。但我仍然在等待安迪·吉尔拿出他神奇的太空泄漏探测器来解决我所有的问题。(在最后一次国际刑事法庭上,我接受了他对我的即席评论,说他构想出了这个很酷的想法,并承诺要实现它。)

我不会试图说服你,懒惰的评价是世界上最好的东西,但有一些好的地方。我有一些流处理程序,可以让懒惰的列表快速通过各种组合器,这些组合器可以在仅使用3.5 MB左右内存(其中超过2MB的内存是GHC运行时)的情况下,在千兆字节的数据上运行。去年有一个比我聪明的人向我指出,作为一个典型的Haskell程序员,你对懒惰的评估有多依赖,这真的会让你大吃一惊。

但是我们真正需要的是一本关于处理现实世界中的懒惰评估的好书(这与学术界没有太大的区别,真的,除了他们没有发表论文,而且我们的客户拿着刀追着我们),这本书将适当地涵盖与此相关的大多数问题,更重要的是,给我们提供一个对什么会爆炸我们的堆什么不会爆炸的直觉。

我不认为这是一件新的事情;我相信其他语言和体系结构也经历过这件事。第一批程序员是如何处理硬件堆栈的呢?不太好,我敢打赌。

我想简·威廉·马森的 pH compiler 是严格的。下一个最接近的是罗伯特·埃纳尔(RobertEnnal)对5号温室气体排放量的投机评估叉。spec-eval fork不是严格的,而是乐观地评估。我不知道其中一个是否仍然是最新的/可用的/等等。

到处使用nfdata和rnf并不是一个解决方案,因为它意味着反复遍历已经评估过的大型结构。

本·利普迈尔博士论文(关于DDC)的导论部分是关于我所见过的对哈斯克尔的最好的批判——它讨论了懒惰、破坏性更新、单元变压器等问题。DDC有懒惰,但你必须明确要求,它被认为是一种效果,由DDC的类型和效果系统跟踪和管理。

我最近在这方面看到了一些工作:

https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

您可以在SPJ的GHC状态更新中听到一些关于它的信息:

http://youtu.be/Ex79K4lvJno?t=9m33s (链接从相关部分9:33开始)

我正在寻找一个默认使用严格评估而不是懒惰评估的haskell编译器。

这样的编译器不是haskell编译器。如果你 真的? 想要,你可以考虑 {-# LANGUAGE Strict #-} 文件中的pragma。这将与GHC 8.0.2、8.2.2和8.4.1(即编译器的最后三个版本)一起工作。

如果有一种方法可以在某些地方使用懒惰的评估,这也会很有帮助,以防我想要一个无限列表之类的东西。

没有这样的方法。相反,使用GHC作为一种懒惰的语言。学习如何正确地考虑代码、概要文件和使用功能数据结构将比在任何地方不加考虑地应用严格的语用更加有用。GHC已经有了一个严格的分析仪。

(我可能永远不会)。

这正是llvm-hs的作者 thought 当他们选择使用严格的单子状态而不是懒惰的状态时。相反,它在路上引起了一个意想不到的虫子。懒惰和递归是并驾齐驱的。

请不要试图说服我,懒惰的评价更好,我真的需要表现。

我怀疑这实际上是你想要的,当它不能可靠地提高haskell代码的性能,同时破坏现有代码和使现有资源无用时。如果您打算这样编写程序,请使用ocaml或scala,不要使用haskell社区。

国际研究所的西蒙·佩顿·琼斯甚至说,懒惰的评估并不是真正必要的,主要是为了防止他们让语言变得不纯洁。

这不是真的。你可以阅读更多关于哈斯克尔的实际历史。 here

也有 seqaid 这是针对懒惰严格光谱的中间部分。

Seqaid是一个GHC插件,为Haskell项目提供非侵入性自动检测,用于动态严格性(和并行性)控制。这将很快包括优化自动空间泄漏救济使用最小的严格。

你显然已经决定了严格评估的价值,但我认为你错过了使用haskell的意义。Haskell的惰性评估允许编译器/解释器使用更灵活的优化策略。强制您自己的严格性会覆盖优化器。最后,使用过度严格的评估永远不会像自动优化那样有效。尝试在ghci中对一系列数字进行折叠和运算,然后进行不延迟的计算。您可以非常清楚地看到差异——在这种情况下,延迟评估总是更快的。