调试 haskell 代码的好方法是什么？
我已经使用了 ghci 调试器，但我真的更喜欢它与文本编辑器的某种集成，以简化设置断点的过程。 它可能不应该严格评估每个可见变量，但至少应该简化查看本地状态的过程。
我最近发现跟踪功能非常有用，它允许从其他困难的地方进行调试打印输出。
I have used the ghci debugger but would really prefer if it was somewhat integrated with a text editor to simplify the process of setting breakpoints. It should probably not strictly evaluate every visible variable but at least simplify the process of looking at the local state.
I recently found the trace function which has been helpful by allowing debug printouts from otherwise hard places.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
调试 Haskell 代码的一个好方法是使用 QuickCheck 编写和测试代数定律和 SmallCheck。 已有多种 Haskell 调试器，包括 Hat、Hood 和 Freya，但它们都没有被认为具有足够的价值，值得长期维护。
当使用 Haskell 时，你必须以不同的方式思考如何做事。 QuickCheck 页面上的 ICFP 论文提供了一些很好的示例来帮助您入门。 如果您想要一个真实的示例，
xmonad已使用 QuickCheck 进行了广泛的调试。A good way to debug Haskell code is to write and test algebraic laws using QuickCheck and SmallCheck. There have been several Haskell debuggers including Hat, Hood, and Freya, but none of them have been perceived as sufficiently valuable to be worth maintaining for a long time.
When it's Haskell, you have to think differently about how to do things. The ICFP paper on the QuickCheck page has some good examples to get you started. If you want a real-world example
xmonadis extensively debugged using QuickCheck.是的，GHCi 调试器的前端将是一件好事。 也许我们会在下一次黑客马拉松期间完成一些事情。 然而，与此同时：
另外，Haskell 非常适合使用 QuickCheck 进行自下而上的测试。 即，单独测试您的组件，然后将它们组合在一起。 如果您的代码是纯粹的，那么这通常可以正常工作。
Yes, a frontend for the GHCi debugger would be a good thing. Maybe we'll get something done during the next Hackathon. However, in the mean time:
Alternatively, Haskell lends itself nicely to bottom-up testing using QuickCheck. I.e., test your components individually, then put them together. If your code is pure this often Just Works.
附带说明一下，请注意，在调试多线程程序时，
Debug.trace不会成为您的朋友。从长远来看，测试是一条出路。
As a side note, be aware that
Debug.tracewill NOT be your friend when debugging multithreaded programs.Testing is the way to go in the long run.
就我自己而言，我发现这是多种因素的结合。
从其他答案中可以看出，很多人喜欢 QuickCheck 。 我发现很难为至少部分代码定义有意义的 QuickCheck 测试用例，因此通常更多地使用标准单元测试。 话虽如此，第 11 章。
如果您发现自己同时使用 QuickCheck 和 HUnit，您可能需要查看 测试框架。
For my own purposes I find that it's a combination of factors.
As seen in other answers, a lot of people love QuickCheck. I've found it difficult to define meaningful QuickCheck test cases for at least some of my code so generally make more use of standard unit tests. That being said, there's an excellent introduction to using QuickCheck in Chapter 11 of Real World Haskell.
Should you find yourself using both QuickCheck and HUnit, you may want to look into test-framework.