我使用了 ghci 调试器，但如果它在某种程度上与文本编辑器集成以简化设置断点的过程，我会更喜欢它。它可能不应该严格评估每个可见变量，但至少简化查看本地状态的过程。
我最近发现了跟踪功能，它允许从其他困难的地方进行调试打印输出。
user53067
问问题
8536 次
4 回答
13
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 xmonad is extensively debugged using QuickCheck.
于 2009-03-24T02:57:07.927 回答
9
是的，GHCi 调试器的前端将是一件好事。也许我们会在下一次黑客马拉松期间完成一些事情。然而，与此同时：
- Monad Reader, Issue 10 (PDF)有一篇关于使用调试器的文章。也许这可以给你更多的提示。
或者，Haskell 非常适合使用 QuickCheck 进行自下而上的测试。即，单独测试您的组件，然后将它们放在一起。如果您的代码是纯的，这通常可以正常工作。
于 2009-03-23T14:32:09.387 回答
5
作为旁注，请注意Debug.trace在调试多线程程序时不会成为您的朋友。
从长远来看，测试是必经之路。
于 2009-03-25T23:41:38.520 回答
3
For my own purposes I find that it's a combination of factors.
- Write easy to debug functional code, this means to make sure your functions are relatively small (5-20 lines) and that they only do one clearly defined thing each.
- Use HUnit to define test cases that will bring out your problems.
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.
于 2009-04-01T15:58:38.203 回答