※ 引述《godfat (godfat 真常)》之铭言： : 推 ephesians:lazy是用来节省计算成本,结果仍浪费成本啊! XD 03/02 06:45 : 能越早做 eval 或 binding 执行效率当然会越高，我觉得大部份的情况下 : 还是需要 eager eval, 只有很少数是真的需要用 lazy eval. 当然，这是 : 指使用 imperative 之形式的话，funational 又是另一回事了 @@ 我记得有研究分析过真正使用 non-strictness(*) 的时机到底有 多少，结论是不多，所以不值得(像 Haskell 这样)把它当作 default. 不过我可能记错。 (*) 严格说起来，lazy evaluation 只是一种实作 non-strict 语意的方法之一（还有其他的方法）。不过 lazy evaluation 这个词念起来比较 印象深刻，所以实际上常常混用。 我之前不知道 D 这个语言。看前一篇的描述，似乎就颇像是把 eager 当作 default, 需要 lazy 的时候再特别宣告一下。 对我来说，我是已经很习惯 laziness 了，并不知道自己真的是否 有用到，只觉得如果没有会怪怪的。 ＊ ＊ ＊ 关於 log 的例子指出了重要的一点: non-strictness 提供了另一种 模组化的可能。像 log 如果不是 non-strict 的，就没法独立出来变 成一个可重用的函数。 「Lazy evaluation 省计算」这件事情其实是个误解/误导。举个例子， 如果要算 n 阶层，我们可以先产生 [1,2,3...,n] 的串列，然後把它 乘起来；要产生 [1,2,3..n] 这个串列，可以先产生一个从 1 开始 的无限长串列(写成 [1..] )然後取前面 n 个。所以可以这麽做: foldr (*) 1 (take n [1..]) 其中 take n 取串列的前面 n 个元素， foldr (*) 1 把他们 乘起来。可是先产生一个长串列、再截一段出来、再乘起来，不是很 费工又耗记忆体吗？我们说，没关系，在 lazy evaluation 之下， 只有使用到的地方才会去计算，所以其实这个程式用的是 constant space, 而且也没有真的去产生无限长的串列。 所以 lazy evaluation 省时间/空间？其实没有这回事，因为所谓 省是要看和谁比。如果今天是用一个 eager 的语言，程式根本就 不会这样写。Lazy evaluation 「省」出来的结果，其实和一个 eager 程式本来会写成的样子是一样的。而且 laziness 还会有些 overhead. 那 laziness (或 non-strictness) 的好处是什麽？其一是这些 take, foldr, map 等等函数都是可以在很多场合下重复使用的元件。 Non-strictness 增加了模组化的可能。其二是我们能表达「无限长 的串列」这种东西。 论效率的话，目前的 lazy 语言还是比较难实作得有效率。有人 提出一种所谓的「lenient evaluation」，认为是 lazy 与 eager 之间折衷的好方法。不过是否真如此就还需要研究了。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.109.20.217