haskell - TCO 在 Clojure 中优化了汉诺塔

Question

我正在阅读 Introdution to Haskell当然，他们正在介绍著名的汉诺塔问题作为第一个类的家庭作业。我被诱惑并写了一个解决方案:

type Peg = String

type Move = (Peg, Peg)

hanoi :: Int -> Peg -> Peg -> Peg -> [Move]
hanoi n b a e
  | n == 1 = [(b, e)]
  | n > 1 = hanoi (n - 1) b e a ++ hanoi 1 b a e ++ hanoi (n - 1) a b e
  | otherwise = []

我试了一下，发现它显然使用了尾调用优化，因为它在常量内存中工作。

Clojure 是我大部分时间使用的语言，因此我受到了编写 Clojure 解决方案的挑战。天真的被丢弃了，因为我想写它来使用 TCO:

(defn hanoi-non-optimized
  [n b a e]
  (cond
    (= n 1) [[b e]]
    (> n 1) (concat (hanoi-non-optimized (dec n) b e a)
                    (hanoi-non-optimized 1 b a e)
                    (hanoi-non-optimized (dec n) a b e))
    :else   []))

好吧，Clojure 是 JVM 托管的，因此默认情况下没有 TCO，应该使用 recur 来获取它(我知道这个故事......)。另一方面，recur 强加了一些句法约束，因为它必须是最后一个表达式 - 必须是尾部。我感觉有点糟糕，因为我仍然无法编写一个像 Haskell 中那样简短/富有表现力的解决方案，同时使用 TCO。

有没有我目前看不到的简单解决方案？

我非常尊重这两种语言，并且已经知道这是我的方法的问题，而不是 Clojure 本身的问题。

Answer 1

不，Haskell 代码不是尾递归的。它是 guarded 递归的，递归由惰性数据构造函数 : 保护(++ 调用最终转换为它)，其中由于惰性，只有递归调用树的一部分 (a++ b++ c) 依次被探索，所以堆栈的深度永远不会超过 n，磁盘数量。这是非常小的，比如 7 或 8。

因此 Haskell 代码探索 a，将 c 部分放在一边。另一方面，您的 Clojure 代码会计算两部分(a 和 c，因为 b 不算在内)之前 连接它们，所以是双递归，即计算量大。

您要查找的不是 TCO，而是 TRMCO -- tail recursion modulo cons优化，即从具有模拟堆栈的循环内部以自上而下的方式构建列表。 Clojure 特别适用于此，它的尾部附加 conj(对吧？)而不是 Lisp 和 Haskell 的头部附加 cons。

或者只是打印移动而不是构建所有移动的列表。

编辑:实际上，TRMCO 意味着如果我们自己维护“连续堆栈”，我们就可以重用调用帧，因此堆栈深度恰好变为 1。在这种情况下，Haskell 很有可能构建一个由嵌套的 ++ thunk 节点组成的左加深树，如 here 所解释的那样，但在 Clojure 中，当我们维护自己的to-do-next 调用描述堆栈时(对于a++ b++ c 表达式的 b 和 c 部分。