是否有使用严格评估的Haskell编译器或预处理器？

Question

我正在寻找一个Haskell编译器，该编译器默认情况下使用严格的评估而不是懒惰评估。我只会使用ocaml，但是哈斯克尔的语法是 好多了 比Ocaml的（Haskell是纯净的，并且具有诸如类型类之类的很酷的功能）。

我真的宁愿不经常放 !沙 $!整个程序。带有开关或预处理器进行严格注释的编译器真的很好。如果有一种方法也可以在某些地方使用懒惰评估，以防万一我想要一个无限列表（我可能永远不会），这也将有所帮助。

请不要试图说服我懒惰的评估更好，我真的需要表演。 IIRC，西蒙·佩顿·琼斯（Simon Peyton Jones）甚至说，懒惰的评估并不是真正的必要，主要是为了防止他们使语言变得不纯净。

Answer 1

如果您有使用严格评估的Haskell编译器，则不会编译Haskell。 懒惰 非严重性是Haskell规格的一部分！

但是，有其他选择。

• DDC 试图创建一个明显的Haskell懒惰变体，该变体支持诸如破坏性更新之类的东西，同时保留Haskell的其余部分。有一个问题：编译器目前仅在α阶段，尽管它至少至少可用。

• 像其他人一样创建一个预处理器。

• 学习使用Haskell“正确的方式”。如果您可以将测试用例简化为可公开播放的东西，则可以将其发布到 Haskell-Café邮件列表, ，人们对有关非严重性影响的这类问题非常有帮助。

Answer 2

我真的宁愿不经常投入！S和$！S

您做错了，如果这是您编程Haskell的方式：）您根本不需要这样做。使用GHC，使用-O2，在适当的情况下使用严格的数据类型，在适当时使用懒惰的数据类型。不要以为懒惰是一个问题 - 这是解决很多问题的方法。

Answer 3

过去有两次严格评估Haskell的尝试：

• Jan-Willem Maessen的 渴望哈斯克尔
• Rob Ennals 博士论文

但是两者都专注于坚持Haskell的非图案语义，但使用了大多数图片的评估策略，而不是实际改变语义，并且从未真正看到过一天的光芒。

编辑：Martijn关于严格的包木的建议看起来是您真正想要的，并且作者仍然活跃于Haskell社区，我忘记了这一点。

Answer 4

也可以看看 GHC-Strict-Plugin, ，一个例子 GHC的插件框架, ，在 MONAD读者12.

Answer 5

我感到你的痛苦。我在日常编程中最大的PITA是处理这些问题！@＃$％^＆（太空泄漏。

但是，如果有帮助的话，随着时间的流逝，您确实会学习如何处理此问题，并且确实会变得更好。但是我仍在等待安迪·吉尔（Andy Gill）和他的神奇空间泄漏探查器出来，以解决我的所有问题。 （我在最后一个ICFP上向我发表了他的评论，他梦想着这个很酷的想法是实施它的承诺。）

我不会试图说服您懒惰的评估是世界上最好的事情，但是关于它有一些好处。我有一些流式处理程序，可以通过任何多种组合器列出懒惰的列表，这些组合器仅使用3.5 MB左右的内存（其中2MB以上是GHC运行时），这些组合量会愉快地运行在千兆内的数据上。去年，我对我指出的聪明的人说，作为典型的Haskell程序员，您真的会感到非常惊讶，您对懒惰的评估有多依赖。

但是，我们真正需要的是一本关于处理现实世界中懒惰评估的非常好的书（这与学术界没有什么不同，实际上，除了他们根本没有发表论文，我们让客户追随我们使用刀具）可以正确涵盖与此有关的大多数问题，更重要的是，让我们直观地了解要爆炸的堆，什么不是。

我认为这不是新事物。我敢肯定，其他语言和架构也经历过。毕竟，第一批程序员如何处理硬件堆栈以及所有这些？我敢打赌，不太好。

Answer 6

我认为Jan-Willem Maessan的 PH编译器 是/严格。下一个是GHC 5的Robert Ennal的投机性评估叉。Spec_eval叉并不严格，而是乐观地评估。我不知道其中任何一个是否仍然是当前/usable/etc。

Answer 7

到处使用NFDATA和RNF并不是一个解决方案，因为它意味着反复穿越已经评估的大型结构。

Ben Lippmeier的博士学位论文（关于DDC）的介绍性章节是关于我看到的最佳批评，它讨论了懒惰，破坏性更新，Monad Transformers等问题。DDC具有懒惰，但您必须明确要求它。 ，它被认为是一种效果，该效果由DDC的类型和效应系统跟踪和管理。

Answer 8

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

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

您可以在SPJ的GHC状态更新中听到有关它的一小部分：

http://youtu.be/ex79k4lvjno?t=9m33s（链接从9:33的相关作品开始）

Answer 9

我正在寻找一个Haskell编译器，该编译器默认情况下使用严格的评估而不是懒惰评估。

这样的编译器将不是Haskell编译器。如果你 真的 想要，您可以考虑放置 {-# LANGUAGE Strict #-} 您的文件中的布拉格马斯。这将与GHC 8.0.2、8.2.2和8.4.1一起使用，也就是编译器的最后三个版本。

如果有一种方法也可以在某些地方使用懒惰评估，以防万一我想要像无限列表一样，这也将有所帮助

没有这样的方法。取而代之的是，将GHC按照预期作为懒惰的语言。学会正确思考您的代码，配置文件和使用功能数据结构将比无意识地应用到各地的严格布拉格斯更有用。 GHC已经有一个严格的分析仪。

（我可能永远不会）。

这正是LLVM-HS的作者 想法 当他们选择使用严格的状态单片而不是懒惰的国家时。相反，这引起了意外的错误。懒惰和递归齐头并进。

请不要试图说服我懒惰的评估更好，我真的需要表演。

我很可疑，这实际上是您想要的，当它不能可靠地提高Haskell代码的性能，同时损坏现有代码并使现有资源毫无用处。如果这是您打算编写程序的方式，请只使用Ocaml或Scala，然后让Haskell社区独自一人。

IIRC，西蒙·佩顿·琼斯（Simon Peyton Jones）甚至说，懒惰的评估并不是真正的必要，主要是为了防止他们使语言变得不纯净。

那不是真的。您可以阅读有关Haskell的实际历史的更多信息 这里

Answer 10

也有 seqaid, ，针对懒惰谱系的中间。

Seqaid是一个GHC插件，可为Haskell项目提供非侵入性自动启示，以进行动态严格（和并行性）控制。这很快将包括使用最小的严格化来优化自动空间泄漏的泄漏。

Answer 11

您显然已经决定了严格评估的价值，但我认为您缺少使用Haskell的意义。 Haskell的懒惰评估允许编译器/口译员采用更灵活的优化策略。强迫自己的严格性覆盖优化器。最后，使用过多的严格评估永远不会像自动化优化那样有效。在GHCI中的数字序列上，在没有懒惰评估的情况下尝试折叠总和。您可以清楚地看到差异 - 在这种情况下，懒惰评估总是更快。