FRP如何處理內存？

Question

閱讀FRP（ 功能反應式編程 ）我很驚訝它與標准命令式方法相比有多么直觀和合乎邏輯; 然而有一件事讓我感到困惑..計算機如何立即耗盡內存呢？

根據我從[ 這里 ]收集到的，在FRP中，價值變化的完整歷史（過去，現在和未來）是一流的 。 這個概念立即在我腦海中響起一個警報，說如果它在一個沒有立即從記憶中清除過去的值的環境中使用，它必須非常快地消耗你的記憶。

閱讀[ Fran ]，我注意到幾個例子已經遞歸地定義了沒有終止條件的函數。 如果函數永遠不會終止並將其值返回給調用它的函數，它將如何完成任何工作？ 或者就此而言，一段時間之后怎么沒有吹掉堆棧呢？ 即使是像Haskell這樣的惰性語言也會在某些時候遇到堆棧溢出。

對這些事情的解釋將非常感激，因為它完全讓我感到困惑。

Answer 1

事實上，這可以用於簡單的情況不應該是一個驚喜：由於懶惰和垃圾收集，我們已經在Haskell中舒適地使用無限數據結構。 只要您的最終結果不依賴於同時擁有所有值，就可以在您開始時收集它們，或者在第一時間不強制它們。

這就是為什么這個經典的Fibonacci例子在常數¹空間中運行的原因：一旦計算了下兩個，就不需要列表中的前一個條目，所以只要你沒有任何其他指向列表的指針就會收集它們。

fib n = fibs !! n
  where fibs = 0 : 1 : zipWith (+) fibs (drop 1 fibs)

嘗試針對不同的輸入運行此函數並查看內存使用情況。 （用+RTS -s運行它。）

（如果你想用圖表更詳細的解釋，請看看我寫的這篇文章 。）

關鍵是，即使程序員可以獲得無限量的信息，如果沒有別的東西依賴它，我們仍然可以收集大部分信息。

完全相同的邏輯可用於有效地實施FRP程序。

當然，一切都不那么容易。 在fibs示例中，如果我們有一個指向fibs列表開頭的活動指針，內存使用率會上升。 如果您的計算依賴於過多的過去數據，那么FRP也會發生同樣的事情：它被稱為時間泄漏 。

處理時間泄漏是實施高效，良好行為的FRP框架的一個懸而未決的問題。 很難提供富有表現力的FRP抽象，但不允許使用差的甚至是災難性的內存。 我相信大多數當前的方法最終會提供抽象的FRP類型以及一系列有效的操作，這些操作不太可能導致這些類型的泄漏; 這種特別極端的形式是Arrowized FRP，它根本不提供行為/信號類型，而是用信號之間的轉換表示所有內容（如箭頭所示）。

我自己從未嘗試過實施一個好的FRP系統，所以我無法更詳細地解釋這些問題。 如果你對這個主題的更多細節感興趣，那么一個很好看的地方是Conal Elliott的博客 - 這篇文章是一個很好的起點。 你還可以看看他寫的一些論文，如“Push-Pull Functional Reactive Programming”以及其他有關該主題的論文，包括一些關於Arrowized FRP的文章，如“功能反應編程，續” （幾乎隨機選擇） 。

腳注

¹這不是真正的恆定空間，因為中間結果會變得更大。 但它應該在內存中保持一定數量的列表單元格。

Answer 2

關於泄漏部分問題的時間：這確實是實施FRP的主要挑戰之一。 然而，FRP研究人員和實施者已經找到了幾種避免它們的方法。

這完全取決於您為信號提供的精確API。 主要問題是您是否提供更高階的FRP 。 這通常采用信號的“monadic join”原語的形式：將信號信號轉換為信號的方式，或者換句話說，用於產生在許多其他信號之間動態切換的信號的API。 這樣的API非常強大，但可能會引入時間泄漏的可能性，即您提出的問題：需要將所有信號的先前值保留在內存中。 然而，正如Heinrich Apfelmus在對先前答案的評論中提到的那樣，有一些方法可以通過使用類型系統或其他方式以某種方式限制高階API來解決這個問題。 請參閱該評論以獲取進一步解釋的鏈接。

許多FRP庫根本不提供更高階的API，因此（非常容易）避免了時間泄漏的問題。 你提到的榆樹，這是在這種情況下，提到這里下的“信號不單子在榆樹”。 這確實是以表現力為代價的，因為沒有提供強大的monadic API，但並不是每個人都認為你需要在FRP框架/庫中使用這種API的一般功能。

最后，我建議Elm的主要作者Evan Czaplicki做一個有趣的演講 ，他很好地解釋了這些問題並提供了解決這些問題的可能方法的概述。 他根據FRP方法的解決方法對FRP方法進行了分類。