方案：`letrec` 和 `letcc` 对效率至关重要吗？

Question

我正在阅读 Friedman 和 Felleisen 的 The Seasoned Schemer，但我对他们的一些最佳实践感到有些不安。 作者特别推荐：

• 使用letrec 删除对于递归应用程序不会更改的参数；
• 使用letrec 隐藏和保护函数；
• 使用letcc 突然而迅速地返回值。

让我们来看看这些规则的一些后果。 例如，考虑以下用于计算列表列表交集的代码：

#lang scheme

(define intersectall
  (lambda (lset)
    (let/cc hop
      (letrec
          [[A (lambda (lset)
                (cond [(null? (car lset)) (hop '())]
                      [(null? (cdr lset)) (car lset)]
                      [else (I (car lset) (A (cdr lset)))]))]
           [I (lambda (s1 s2)
                (letrec
                    [[J (lambda (s1)
                          (cond [(null? s1) '()]
                                [(M? (car s1) s2) (cons (car s1) (J (cdr s1)))]
                                [else (J (cdr s1))]))]
                     [M? (lambda (el s)
                           (letrec
                               [[N? (lambda (s)
                                      (cond [(null? s) #f]
                                            [else (or (eq? (car s) el) (N? (cdr s)))]))]]
                             (N? s)))]]
                  (cond [(null? s2) (hop '())]
                        [else (J s1)])))]]
        (cond [(null? lset) '()]
              [else (A lset)])))))

这个例子出现在第 13 章（不完全是这样：我粘贴了在前一段中单独定义的成员测试代码）。

我认为下面的替代实现，它对letrec 和letcc 的使用非常有限，更具可读性和更易于理解：

(define intersectall-naive
  (lambda (lset)
    (letrec
        [[IA (lambda (lset)
              (cond [(null? (car lset)) '()]
                    [(null? (cdr lset)) (car lset)]
                    [else (intersect (car lset) (IA (cdr lset)))]))]
         [intersect (lambda (s1 s2)
                      (cond [(null? s1) '()]
                            [(M? (car s1) s2) (cons (car s1) (intersect (cdr s1) s2))]
                            [else (intersect (cdr s1) s2)]))]
         [M? (lambda (el s)
               (cond [(null? s) #f]
                     [else (or (eq? (car s) el) (M? el (cdr s)))]))]]
    (cond [(null? lset) '()]
          [else (IA lset)]))))

我是 scheme 新手，我的背景不是计算机科学，但让我感到震惊的是，对于一个简单的列表交集问题，我们必须以如此复杂的代码结束。这让我想知道人们如何管理现实世界应用程序的复杂性。 经验丰富的策划者是否每天都在深度嵌套 letcc 和 letrec 表达式？

这就是询问 stackexchange 的动机。

我的问题是：Friedman 和 Felleisen 是否为了教育而过度复杂化了这个示例，还是出于性能原因我应该习惯于使用充满 letccs 和 letrecs 的方案代码？ 对于大型列表，我的幼稚代码是否会变得非常慢？

Answer 1

我不是 Scheme 实现方面的专家，但我对这里发生的事情有一些想法。作者通过他们的let/cc 拥有的一个您没有的优势是在清楚整个结果将是什么时提前终止。假设有人评估

(intersectall-naive (list big-list
                          huge-list
                          enormous-list
                          gigantic-list
                          '()))

您的 IA 会将其转换为

(intersect big-list
           (intersect huge-list
                      (intersect enormous-list
                                 (intersect gigantic-list
                                            '()))))

这很合理。最里面的交集将首先被计算，并且由于gigantic-list 不为零，它将遍历整个gigantic-list，为每个项目检查该项目是否是'() 的成员。当然，没有一个，所以这会导致'()，但您确实必须遍历整个输入才能找到它。这个过程将在每个嵌套的intersect 调用中重复：您的内部过程无法发出“没希望了，放弃吧”的信号，因为它们仅通过返回值进行通信。

当然，您可以在不使用let/cc 的情况下解决此问题，方法是在继续之前检查每个intersect 调用的返回值是否为空。但是（a）让这个检查只发生在一个方向而不是两个方向上是相当漂亮的，并且（b）并不是所有的问题都会如此顺从：也许你想返回一些你不能轻易发出信号的东西，即提前退出是需要的。 let/cc 方法是通用的，允许在任何情况下提前退出。

至于使用letrec 来避免重复调用递归调用的常量参数：同样，我不是Scheme 实现方面的专家，但在Haskell 中我听说过这样的指导：如果你只关闭一个参数，那就是洗了，并且对于 2+ 个参数，它可以提高性能。考虑到闭包的存储方式，这对我来说很有意义。但我怀疑它在任何意义上都是“关键的”，除非你有大量的参数或者你的递归函数做的工作很少：参数处理将是完成工作的一小部分。如果作者认为这提高了清晰度，而不是出于性能原因，我不会感到惊讶。如果我看到

(define (f a x y z)
  (define (g n p q r) ...)
  (g (g (g (g a x y z) x y z) x y z) x y z))

如果我看到了，我会更不开心

(define (f a x y z)
  (define (g n) ...)
  (g (g (g (g a)))))

因为我必须发现实际上p 只是x 等的另一个名称，请检查是否在每种情况下都使用相同的x、y 和z，并确认这是故意的。在后一种情况下，很明显x 始终具有该含义，因为没有其他变量持有该值。当然，这是一个简化的例子，无论如何我不会很高兴看到 g 的四个字面应用，但同样的想法也适用于递归函数。