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