有人可以解释Haskell记忆化背后的概念吗？

（请注意，我将问题放在这里是因为它是关于它的概念机制，而不是编码问题）

我当时正在开发一个小型程序，该程序在其等式中使用了斐波那契数列，但是我注意到，如果超过一定数，它会变得非常缓慢，在谷歌上徘徊了一段时间，我偶然发现了Haskell中一种称为的技术Memoization，他们展示了这样的代码：

-- Traditional implementation of fibonacci, hangs after about 30
slow_fib :: Int -> Integer
slow_fib 0 = 0
slow_fib 1 = 1
slow_fib n = slow_fib (n-2) + slow_fib (n-1)

-- Memorized variant is near instant even after 10000
memoized_fib :: Int -> Integer
memoized_fib = (map fib [0 ..] !!)
   where fib 0 = 0
         fib 1 = 1
         fib n = memoized_fib (n-2) + memoized_fib (n-1)

所以我对你们的问题是，为什么或如何运作？

是因为它以某种方式设法在计算赶上之前遍历了大多数列表吗？但是，如果haskell很懒惰，那么实际上并不需要进行任何计算...那么它如何工作？

只是为了解释实际记忆背后的机制，

memo_fib = (map fib [1..] !!)

产生未分类计算的“ thunks”列表。将它们视为未打开的礼物，只要我们不触摸它们，它们就不会运行。

现在，一旦我们评估了重击，就再也不会评估。实际上，这是“正常” haskell中唯一的突变形式，暴徒一旦被评估为具体值，就会突变。

回到您的代码，您将获得一个thunk列表，并且仍然进行此树递归，但是您使用该列表进行递归，并且一旦对列表中的一个元素进行求值，就永远不会再进行计算。因此，我们避免了朴素的fib函数中的树递归。

作为切线有趣的注释，这在计算一系列斐波那契数字时特别快，因为该列表仅被评估一次，这意味着如果您计算memo_fib 10000两次，则第二次应该是瞬时的。这是因为Haskell只对函数的参数求值一次，而您使用的是部分应用程序而不是lambda。

TLDR：通过将计算结果存储在列表中，列表中的每个元素都会被评估一次，因此，在整个程序中，每个斐波那契数都将被精确地计算一次。

可视化：

 [THUNK_1, THUNK_2, THUNK_3, THUNK_4, THUNK_5]
 -- Evaluating THUNK_5
 [THUNK_1, THUNK_2, THUNK_3, THUNK_4, THUNK_3 + THUNK_4]
 [THUNK_1, THUNK_2, THUNK_1 + THUNK_2, THUNK_4, THUNK_3 + THUNK_4]
 [1, 1, 1 + 1, THUNK_4, THUNK_3 + THUNK_4]
 [1, 1, 2, THUNK_4, 2 + THUNK4]
 [1, 1, 2, 1 + 2, 2 + THUNK_4]
 [1, 1, 2, 3, 2 + 3]
 [1, 1, 2, 3, 5]

因此，您可以看到评估THUNK_4的速度更快，因为它的子表达式已经被评估了。

记忆的重点是永远不要两次计算相同的函数-这对于加速纯函数的计算（即无副作用）非常有用，因为对于那些函数而言，该过程可以完全自动化而不影响正确性。对于像这样的函数，在天真地实现时fibo会导致树递归（即指数级的努力），这尤其必要。（这就是为什么斐波那契数实际上不是一个很好的递归教学例子的原因-您在教程或书籍中发现的几乎所有演示实现都不适用于较大的输入值。）

如果跟踪执行流，您会发现在第二种情况下，for的值fib x在fib x+1执行时将始终可用，并且运行时系统将能够简单地从内存中读取它，而无需通过另一个递归调用，而第一个解决方案尝试在获得较小值的结果之前计算较大的解决方案。最终这是因为迭代器[0..n]是从左到右求值的，因此将从那里开始0，而第一个例子中的递归从那里开始，n然后才问一下n-1。这就是导致许多很多不必要的重复函数调用的原因。