Haskell中的WHNF減少是否發生在編譯時？

Question

AFAIU由Haskell compiler生成的目標文件應該是機器代碼。 那么該目標文件是否具有原始AST的表示並在運行時減少它，或者這種減少是在編譯時發生的，並且只有最終的WHNF值被轉換為相應的機器代碼。

我理解后者的編譯時間是程序本身時間復雜度的函數，我認為不太可能。

有人可以清楚地解釋運行時會發生什么以及在Haskell (GHC)的情況下編譯時會發生什么？

Answer 1

編譯器可以在運行時執行其所有減少的工作。 也就是說，生成的可執行文件可以具有（大）數據部分，其中整個程序AST被編碼，以及（小）文本/代碼部分具有在AST上操作的通用WHNF縮減器。

請注意，上述方法適用於任何語言。 例如，Python編譯器也可以生成包含AST數據和通用reducer的可執行文件。 reducer將遵循語言的所謂小步語義 ，這是計算機科學中更為人熟知的概念（更具體地說，在編程語言理論中）。

但是，這種方法的表現會很差。

編程語言的研究人員致力於尋找更好的方法，從而導致抽象機器的定義。 本質上，抽象機是用於在較低級別設置中運行高級程序的算法。 通常，它利用一些數據結構（例如堆棧）來使過程更有效。 對於Haskell等函數式語言，眾所周知的抽象機器包括：

• 分類抽象機 （Caml最初使用它，我認為）
• Krivine機器
• SECD
• Spineless無標簽G機 （GHC使用這個）

問題本身遠非微不足道。 已經有，並且我認為仍有研究使WHNF降低效率更高。

在GHC編譯之后，每個Haskell定義都成為一系列匯編指令，它們操縱STG機器的狀態。 周圍沒有AST，只有操作數據/閉包等的代碼。

可以說，使用這些先進技術來提高性能以及大量優化是非常重要的。 然而，一個消極的后果是，很難理解原始代碼的結果代碼的性能，因為需要考慮抽象機器的工作方式（這是非常重要的）和優化（非常復雜）如今）。 在較小程度上，這也是大量優化C或C ++編譯器的情況，在這種情況下，更難以了解何時觸發優化。

最終，有經驗的程序員（在Haskell，C，C ++或其他任何方面）將會理解其編譯器的基本優化，以及正在使用的抽象機器的基本機制。 但是，我認為這不是一件容易掌握的事情。

在這個問題中，提到WHNF減少可以在編譯時執行。 這只是部分正確，因為直到運行時才能知道源自IO動作的變量的值，因此減少只能在涉及這些值的運行時發生。 此外，執行減少也會使性能變差！ 例如

let x = complex computation in x + x
-- vs
complex computation + complex computation

后者是減少前者的結果，但它重復了工作！ 實際上，大多數抽象機器都使用惰性約簡方法，這使得x在這種情況下只能計算一次。