如何在惰性函数式编程语言中实现调试?

时间:2009-08-20 03:29:31

标签: debugging functional-programming lazy-evaluation

我想知道如何用惰性函数语言实现调试 你能使用断点,印刷语句和传统技术吗?这是一个好主意吗? 我的理解是纯函数式编程不允许副作用,monad除外 执行顺序也不能得到保证 您是否需要为要测试的每个代码段编写一个monad? 我想从这个领域更有经验的人那里了解这个问题。

5 个答案:

答案 0 :(得分:29)

在延迟评估的功能程序中,没有什么可以阻止您使用断点。急切评估的不同之处在于 程序将在断点处停止以及跟踪的样子。当设置断点的表达式实际上正在减少时(显然),程序将停止。

而不是你习惯的堆栈跟踪,你得到的减少导致表达式减少,并带有断点。

小傻的例子。你有这个Haskell程序。

add_two x = 2 + x

times_two x = 2 * x

foo = times_two (add_two 42)

然后在第一行(add_two)上放置一个断点,然后评估foo。当程序在断点处停止时,用一种急切的语言,你会期望有像

这样的痕迹
add_two
foo

times_two甚至还没有开始评估,但在GHCi调试器中你得到了

-1  : foo (debug.hs:5:17-26)
-2  : times_two (debug.hs:3:14-18)
-3  : times_two (debug.hs:3:0-18)
-4  : foo (debug.hs:5:6-27)
<end of history>

这是减少的列表,导致减少断点所在的表达式。请注意,它看起来像times_two“称为”foo,即使它没有明确地这样做。您可以从中看到,2 * x( - 2)中对times_two的评估确实强制从(add_two 42)行评估foo( - 1)。从那里你可以像在命令式调试器中那样执行一个步骤(执行下一个减少)。

在热切的语言中调试的另一个不同之处是变量可能尚未被评估为thunk。例如,在上面跟踪中的步骤-2并检查x,您会发现它仍然是未评估的thunk(在GHCi中用括号表示)。

有关更详细的信息和示例(如何逐步完成跟踪,检查值,......),请参阅GHC手册中的the GHCi Debugger section。还有Leksah IDE我尚未使用,因为我是VIM和终端用户,但它根据手册有一个GHCi调试器的图形前端。

您还要求提供印刷声明。只有使用纯函数,这不是那么容易实现,因为print语句必须在IO monad中。所以,你有一个纯粹的功能

foo :: Int -> Int

并且希望添加一个trace语句,print会在IO monad中返回一个动作,因此你必须调整你希望将trace语句放入的函数的签名,以及函数的签名。叫它,......

这不是一个好主意。所以,你需要一些方法来打破纯度来实现跟踪陈述。在Haskell中,可以使用unsafePerformIO完成此操作。有Debug.Trace模块已经有一个功能

trace :: String -> a -> a

输出字符串并返回第二个参数。编写纯函数是不可能的(好吧,如果你打算真正输出字符串,那就是)。它使用引擎盖下的unsafePerformIO。您可以将其放入纯函数中以输出跟踪打印。

  

您是否需要为要测试的每个代码段编写一个monad?

我建议相反,尽可能多地使用尽可能多的函数(我假设你的意思是IO monad用于打印,monad不一定是不纯的)。延迟评估允许您非常干净地将IO代码与处理代码分开。

命令性调试技术是否是一个好主意取决于具体情况(像往常一样)。我觉得使用QuickCheck / SmallCheck进行测试比命令式语言中的单元测试更有用,所以我首先要走这条路,以避免尽可能多的调试。 QuickCheck属性实际上制作了非常简洁的函数规范(命令式语言中的很多测试代码看起来就像是另一个代码blob。)

避免大量调试的一个技巧是将函数分解为许多较小的子函数,并尽可能多地测试它们。来自命令式编程时,这可能有点不同寻常,但无论您使用何种语言,这都是一个好习惯。

然后再次调试!=测试,如果某处出现问题,断点和跟踪可能会帮助你。

答案 1 :(得分:6)

我认为这个话题不能在短时间内处理。请阅读以下链接中提供的论文:

  1. A Theory of Tracing Pure Functional Programs
  2. The Haskell Tracer publications
  3. Haskell Debugging Technologies

答案 2 :(得分:2)

我从未在Haskell中深入研究任何非常复杂的东西,但副作用几乎消失的事实已经消除了大部分调试需求。无需调试器即可轻松测试和验证纯函数。

另一方面,我确实经历了几次我需要在monad中调试某些东西,在这种情况下我已经能够打印/记录/无论如何。

至少对于较小的程序或系统,调试类型会消失。强类型和静态类型检查确实进一步消除了在程序编程中发现的传统错误。大多数错误(如果有的话)都是逻辑错误(称为错误的函数,数学错误等) - 非常容易以交互方式进行测试。

答案 3 :(得分:1)

Clojure的经验(懒惰,功能性,鼓励但不强制纯洁):

  • 您可以像使用任何其他语言一样设置断点。但是,由于懒惰的评估,这些可能不会立即被调用,但是一旦评估了惰性结构,就会被命中。

  • 在允许副作用的懒惰函数式语言中(包括Clojure),您可以相对容易地插入printlns和其他调试日志记录。我个人认为这些非常有用。由于懒惰,你必须要小心这些被调用的时间,但是如果你根本看不到输出,那么可能暗示你的代码没有被懒惰评估.....

说完以上所有内容之后,我从未需要求助于调试器。通常一些简单的测试(可能在REPL上)足以验证功能代码是否正常工作,如果这些测试失败,那么通常很明显出现了什么问题。

答案 4 :(得分:0)

请允许我宣传我自己的工具来调试懒惰问题。它帮助我在一小时内解决了与懒惰相关的内存泄漏,我已经花了2天的时间进行调试。

http://www.haskell.org/pipermail/haskell-cafe/2012-January/098847.html

http://hackage.haskell.org/package/htrace