何時需要顯式遞歸？

Question

在Haskell中，盡可能在高階函數（如折疊，貼圖和展開）中編寫盡可能多的代碼是慣用的。 那么哪些代碼不能用那些高階函數編寫？ 何時需要顯式遞歸？

Answer 1

讓我們假設我們有一種沒有遞歸的語言或類似的東西。 這意味着沒有循環結構。 這也意味着我們也有（非遞歸）類型，因此我們無法形成Y-combinator並逃脫。 在這種語言中，我們真的很弱，與我們的許多工具分開。

但我們可以就這種語言提出一個非常好的問題。 也就是說，為了使它變得像沒有這種限制的語言一樣強大，我們必須給它最小的東西是什么？

事實證明有兩個答案。

1. 我們可以引入遞歸綁定器，比如let rec命令或類似Haskell的let ，它總是let rec 。 換句話說，一種允許我們let x = e in b定義let x = e in b的結構，使得如果x在e是自由的，那么它被計算為等式x = e上的固定點。

2. 我們可以引入函數fix :: (a -> a) -> a這樣fix f在一步減少到f (fix f) 。

從上面的演示中可以清楚地看出，可以使用遞歸綁定器來實現fix 。 有點不太清楚的是遞歸綁定器可以使用修復從非遞歸綁定器實現，但是我們在這里：

let x = fix $ \this -> e

值this是指整個表達式，最終結合為x這是我們想要什么。

---

那么為什么我會不遺余力地說出以上所有內容呢？

從本質上講，我想說，只要你願意考慮fix該列表，就不可能說遞歸必然是通過像map這樣的HOF組合器來實現的。 我還想爭辯說，該集合中的組合器實現的任何遞歸都可以使用遞歸綁定器“顯式”完成。 他們同樣強大。

當您考慮HOF組合器（如foldr / unfoldr時，有趣的部分會出現。 這些在技術上比fix /遞歸綁定器稍弱 。 優點是，如果您只使用一組選擇的foldr / unfoldr原則構建編程語言，那么您可以獲得一個非常豐富的子圖靈完整語言，該語言可以完全或保證終止。

Answer 2

我想很多人發現遞歸數據定義比Mu / Fix / Nu類型更容易閱讀。 這不是絕對必要的，但在那里非常有用。

類似地，您將通過使用遞歸為這樣的數據類型編寫可折疊/ Unfoldabe實例，但是一旦提供了這些實例，就不需要進行顯式遞歸。