Clojure 中 TCO 优化的河内塔

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 代码不是尾递归的。它是受保护的-递归的，递归由惰性数据构造函数:（++ 调用最终转换为）保护，其中由于惰性，只有递归调用的一部分树 (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 中，我们可以将其重新排列到右嵌套 list我们自己，当我们维护自己的 to-do-next 调用描述堆栈时（对于a ++ b ++ c 表达式的b 和c 部分）。