阅读 FRP（Functional Reactive Programming）与标准命令式方法相比，我对它的直观性和逻辑性感到惊讶；然而有一件事让我感到困惑.. 计算机如何不会立即耗尽内存呢？
根据我从 [here] 收集到的信息，在 FRP 中，值更改的完整历史（过去、现在和未来）是一流时间>。这个概念立即在我脑海中敲响了警钟，说如果它在没有立即从内存中清除过去值的环境中使用，它必须非常快速地消耗你的内存。
阅读 [Fran] 时，我注意到几个示例具有没有终止条件的递归定义函数。如果函数永远不会终止并将其值返回给调用它的函数，它怎么会完成任何事情呢？或者就此而言，它如何在一段时间后不炸毁堆栈？即使是像 Haskell 这样的惰性语言也会在某些时候遇到堆栈溢出。
非常感谢对这些事情的解释，因为它完全让我感到困惑。
【问题讨论】：
标签： haskell memory-management frp
关于时间泄漏部分您的问题：这确实是实施 FRP 的主要挑战之一。然而，FRP 研究人员和实施者已经找到了几种避免它们的方法。
这完全取决于您为信号提供的精确 API。主要问题是您是否提供高阶FRP。这通常采用信号的“monadic join”原语的形式：一种将信号的信号转换为信号的方法，或者换句话说，一种 API 来产生在多个其他信号之间动态切换的信号。这样的 API 非常强大，但可能会引入时间泄漏的可能性，即您提出的问题：需要将所有信号的先前值保存在内存中。但是，正如 Heinrich Apfelmus 在对先前答案的评论中提到的那样，有一些方法可以通过使用类型系统或其他方式以某种方式限制高阶 API 来解决这个问题。请参阅该评论以获取进一步解释的链接。
许多 FRP 库根本不提供高阶 API，因此（很容易）避免了时间泄漏问题。您提到了 Elm，在这种情况下，正如 here 在“信号不是 Elm 中的单子”下提到的。这确实是以表现力为代价的，因为没有提供强大的一元 API，但并不是每个人都认为您需要 FRP 框架/库中这种 API 的通用功能。
最后，我推荐 Elm 的主要作者 Evan Czaplicki 的 an interesting presentation，他很好地解释了这些问题并概述了解决这些问题的可能方法。他根据 FRP 方法的解决方式对其进行分类。
【讨论】：
这对于简单的情况下可以工作这一事实并不令人惊讶：由于惰性和垃圾收集，我们已经在 Haskell 中轻松地使用了无限数据结构。只要您的最终结果不依赖于一次获得所有值，它们就可以在您进行时收集，也可以一开始就没有强制收集。
这就是为什么这个经典的斐波那契示例在恒定空间中运行的原因：列表中的前两个条目在计算完后两个条目后就不需要了，因此它们会随着您的进行而收集——只要您没有任何其他指向列表。
fib n = fibs !! n
where fibs = 0 : 1 : zipWith (+) fibs (drop 1 fibs)
尝试针对不同的输入运行此函数并查看内存使用情况。 （使用+RTS -s 运行它。）
（如果你想要更详细的图表解释，请查看我写的this post。）
关键是，即使程序员可以获得无限量的信息，如果没有其他依赖，我们仍然可以垃圾收集大部分信息。
完全相同的逻辑可以用来高效地实现 FRP 程序。
当然，一切都没有那么容易。在fibs 示例中，如果我们有一个指向fibs 列表开头的活动指针，那么内存使用量将会大幅增加。如果您的计算依赖于过多的过去数据，FRP 也会发生同样的情况：这称为时间泄漏。
处理时间泄漏是实现高效、行为良好的 FRP 框架的未解决问题之一。如果不考虑糟糕甚至灾难性的内存使用的可能性，就很难提供富有表现力的 FRP 抽象。我相信大多数当前的方法最终都会提供抽象的 FRP 类型以及一组不太可能导致此类泄漏的操作；一种特别极端的形式是 Arrowized FRP，它根本不提供行为/信号类型，而是通过信号之间的转换（如箭头）来表达一切。
我从来没有尝试过自己实现一个好的 FRP 系统，所以我无法更详细地解释这些问题。如果您对有关此主题的更多详细信息感兴趣，可以查看 Conal Elliott 的博客 — this post 是一个很好的起点。您还可以查看他撰写的一些论文，例如 "Push-Pull Functional Reactive Programming" 以及有关该主题的其他论文，包括一些关于箭头化 FRP 的论文，例如 "Functional Reactive Programming, Continued"（几乎是随机选择的）。
脚注
¹它不是真正恒定空间，因为中间结果本身会变大。但它应该在内存中保持恒定数量的列表单元格。
【讨论】：