※ 引述《godfat (godfat 真常)》之銘言： : 我有個疑問，purely functional 在處理很多事情上會顯得很麻煩， : 例如 I/O, 或其他本身就具有各種 state 的問題…。如此一來， : purely functional 是否變得有些過分執著…？ 我是覺得還好啦。如果在語意中要描述有副作用的函數, 本來 就是要把 state 當作另一個 argument 傳進去，再把新 state 傳回來。在純 functional 語言中也是這樣寫的。 當然，數學不比程式，前者不怎麼考慮模組化或是維護的問題。 如果程式大了或複雜了，這麼傳來傳去很麻煩而且容易寫錯。 所以 Haskell 是用 monad 把這些細節給包裝起來。 後來這也影響到 semantics 的研究。有些人提倡 semantics 也應該用 monad 組合起來。不過真正這麼做的例子好像不多就是了。 : : 但實際上 "不純" (impure) 的函數式語言反而比較多，像早年比較熱門的 : : LISP, Scheme 到 ML, 或總是被當成明日之星，卻始終沒起色的 Erlang, : : 都不是純函數式語言。 補充一點：以上這些語言都是 eager 的。這可能是因為要在 eager 語言 裡頭加入副作用比較容易，設計的人都蠻難抗拒這誘惑的。多一個 feature 好像也沒什麼不好嘛。 在 lazy 語言之中則不然，因為 lazy 語言中難以預測一段 程式何時真正會被 eval 到。如果有 side effect 往往就天下大 亂了。所以 lazy 語言不得不是 pure 的。 前陣子讀 Haskell 的歷史時讀到這個八卦: 設計 Scheme 時 lazy evaluation 剛剛受到注意。設計者曾考慮過，到底是要 讓 Scheme lazy 還是 eager? 後來選擇了後者，因為他們覺得 在一個 eager 的語言中模擬 lazy evaluation 比較容易。反過 來比較難。 這可能只是習慣的問題。像我就覺得反過來比較容易（只要到處 都加上 case 就好了不是嗎.. ），另一個方向我還真不太會寫。 但總之他們就這麼決定了。如果我沒記錯，當時還沒有 Haskell。 寫這段故事的人說，如果他們決定把 Scheme 設計成一個 lazy 語言，後來的程式語言版圖和演進可能就大大不同了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.192.157.71