我遇到了關于Solo單元素元組的檔案，并且對它如何防止空間泄漏感到有些困惑，這讓我懷疑我不了解 Haskell 記憶體模型和/或垃圾收集器的作業原理。
參考檔案，他們說：
Solo 最重要的特性是可以強制其“外部”（通常通過模式匹配）而不強制其“內部”，因為它被定義為資料型別而不是新型別。這可能有用的一種情況是撰寫函式以從資料結構中提取值時。假設你撰寫了一個陣列的實作并且只提供了這個函式來索引它們：
index :: Array a -> Int -> a現在假設有人想從陣列中提取一個值并將其存盤在惰性值有限映射/字典中：
insert "hello" (arr `index` 12) m這實際上會導致空間泄漏。在強制該值（現在埋在地圖中）之前，該值實際上并未從陣列中提取。這意味著整個陣列可以僅通過該值保持活動狀態！通常，解決方案是使用嚴格的映射，或者在存盤它之前強制該值，但出于某些目的，這是不可取的。
這是我很難理解的。大概a是裝箱的，因此該陣列arr是一個指標陣列（如果它沒有裝箱，則a已經被評估并且這個引數將沒有實際意義）。
所以我猜這個陣列中有這個指標指向arr一個未評估的型別為 thunk a。然后我們將它放在映射中，因此映射現在包含一個指向未計算型別的 thunk 的指標a。現在我不明白為什么這個陣列此時arr需要保持活力。我們在地圖中創建的任何內容都沒有指向arr. 地圖有它自己的指標，指向未評估的 type thunk a，它可以在自己的閑暇時評估它。唯一保持arr活力的可能是未評估的 thunk 取決于 array arr，但如果是這種情況，我不確定將值包裝在Solo資料型別中有何幫助？
我確定我錯過了一些東西。而且我懷疑理解我所缺少的會暴露我上述想法的錯誤。如果我能找出我錯在哪里，那是一件好事。那么有什么想法/解釋嗎？
uj5u.com熱心網友回復：
Haskell 中本質上存在兩種“空間泄漏”。一種是在 thunk 上浪費空間，而早期產生價值會更節省空間。另一個是在大資料結構上浪費空間，而稍后（或根本不）生成它們會更有效率。
作者正在考慮這樣的運算式：
index arr 12
想象這arr是一個大型資料結構，結果是其中包含的單個元素；所做index的就是選擇元素。如果運算式index arr 12保留為 thunk，則 thunk 必然包含對 的參考arr，因此垃圾收集器將無法arr在 thunk 處于活動狀態時回收 的記憶體。
通常顯而易見的事情是安排index arr 12比實際需要的更早執行（正如作者建議的那樣，將其置于嚴格Map而不是懶惰的狀態，但“將其放入地圖”的背景關系實際上并不是必要的）。如果您index arr 12在確定要獲得的內容時強制使用運算式（就像在您將某些內容插入其中時嚴格映射會做的那樣），而不是在您實際將其用于任何事情時，則該函式index已在該點運行完成arr在您使用結果之前，不再需要保留決定和參考。
但是請記住，強制某些東西會將其評估為最外層的資料建構式。index不涉及任何資料建構式，因為它只回傳一個已經存在于arr. 因此，通過評估到達的最外層資料建構式index arr 12將來自元素的任何型別。但是，如果arr（或至少索引 12 處的元素）的元素本身存盤為未評估的 thunk怎么辦？如果這些元素實際上很大，那么完全生成其中一個元素完全有可能并不比存盤一大堆 thunk 1好多少。通過強迫index arr 12早期我們可能避免了一種空間泄漏（保持一個大的 thunk 太久）但導致了另一種（過早地產生一個大的值）。如果不確定所涉及的型別，我們就無法知道哪個更糟！
問題是對最外層資料建構式的評估已經強制“太多”。我們希望評估進行得足夠遠，不再依賴于arr（即知道我們正在回傳它包含的哪些元素），但我們不想實際輸入代表元素的 thunk。
您可以Solo在此處使用的方法是簡單地將資料建構式包裝在回傳的元素周圍，這樣當您強制 thunk 到最外層的建構式時，您就可以到達Solo并且不會再進一步??了。作者指出，對于保存整個陣列的索引 thunk 導致的空間泄漏問題，一個常見的解決方案是“包含一個可以在任意 Applicative 背景關系中產生其結果的索引函式：indexA :: Applicative f => Array a -> Int -> f a”，并且您可以將Solo其用作應用程式將額外的資料建構式放在正確的位置，而無需使用實際上具有任何有趣效果的應用函子。
不過據我了解，包裹Solo只能解決第二個潛在的空間泄漏問題。indexA arr 12 :: Solo a不會神奇地停止，這取決于arr您是否將其保留為 thunk。但是，它使您能夠使用早期評估來解決arr空間泄漏，而不必接受元素本身的潛在泄漏。
1或者簡單地說，完全生產它在時間或空間上的成本很高，我們還不想為此付費。而且可能還沒有絕對確定我們是否要使用它；如果下游消費者不需要它，而我們寧愿不生產它，即使元素比原始陣列小得多（我們所需要的只是它比代表自身的 thunk 小）。
uj5u.com熱心網友回復：
首先，您參考的檔案有一個錯誤，它實際上是相當相關的。
insert "hello" (arr index 12) m
應該
insert "hello" (index arr 12) m
實際上，這確實保存了一個指向arr. 直到index arr 12被評估，它是一個 thunk 持有指向每個index,arr和的指標12。指向index和的指標12不是什么大問題，但arr可能很大。
現在，至于Solo幫助的方式……一般來說不會。這是一個非常奇怪的說法。就像，他們提出了一個功能
indexA :: Applicative f => Array a -> Int -> f a
然后像這樣使用它：
case arr indexA 12 of
Solo a -> insert "hello" a m
但這實際上對任何事情都沒有幫助，除非indexA有一個真正出乎意料的實作。Solo的實作pure是非嚴格的，正如對資料型別的描述所預期的那樣。因此，預期的實作indexA只是將查找結果包裝為pure：
indexA arr i = pure $ index arr i
為了使提供的解釋有意義，實作需要更像這樣：
indexA arr i = pure $! index arr i
我想如果一個庫提供了這個函式，它只有在它有一個更嚴格的實作時才有意義，但我很謹慎地假設這是一個這樣的函式的實作，或者它Solo實際上對解決這個檔案提出的問題很有用。
現在，關于 的嚴格性屬性有一些實際有用的東西Solo，特別是在Monad實體方面。讓我們與 的Monad實體進行對比Identity：
ghci> do { x <- pure () ; y <- undefined ; pure x } :: Identity ()
Identity ()
ghci> do { x <- pure () ; y <- undefined ; pure x } :: Solo ()
*** Exception: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at <interactive>:8:26 in interactive:Ghci4
Solo不被提升的事實Identity使得Monad實體Solo更加嚴格。(>>=)強制在其第一個引數中評估外部Solo建構式，這意味著它實際上會注意到它是否在未使用時將底部值作為其第一個引數。因為Identity建構式在運行時不存在，評估它們只是將所有計算推遲到以后，使得(>>=)實作不那么嚴格
uj5u.com熱心網友回復：
所以我猜這個陣列arr中有一個指向a型別的未評估thunk的指標。然后我們將它放在映射中，因此映射現在包含一個指向 a 型別的未評估 thunk 的指標。現在我不明白為什么這個陣列 arr 在這一點上需要保持活力。
關鍵是，insert "hello" (index arr 12) m 這不僅僅是將現有的未評估的 thunk 放入地圖中。它創建一個新的 thunk 來表示index arr 12，并將其存盤在地圖中。而那個重擊確實需要arr還活著。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/517141.html