※ 引述《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