我正在寻找更多Pro和contras for haskells lazy method
的临 的
的魂斗罗 的
亲切的问候
答案 0 :(得分：4)
首先，lazy evaluation并非在Haskell中发明，将其归类为不正确。
其次，Haskell也有热切的评价（相反;评估何时推荐）的可能性。
第三，懒惰的评估设施也可以用其他语言和技术轻松获得; Python的生成器（回忆xrange函数），Meyers单例和C ++中的模板实例化，延迟了运行时链接器中的符号解析 - 都是这个想法的例子。
所以无论如何，容纳这个想法和相应的词汇永远不会对软件工程师有害。
关于职业选手缺点，你命名为主要的。还有一些可以命名（请记住，您几乎可以使用任何语言进行数据结构和函数调用）：
Recursive datastructures，您可以在其中创建一个列表值，其中元素排列在一个圆圈中，头部是“最后一个”的next元素;遍历这样的列表将产生无限重复的元素序列。可能不是最具激励性的例子，但你可以用树木，图表等来做同样的事情。
使用延迟数据结构而不是内置基元安排控制流;考虑用懒惰列表构建coroutines。这实际上是更复杂和复杂的评估顺序的另一面（即你的一个 contra 是一个优势）。
计算的半自动并行化。这更多是referential transparency的优势，而不是懒惰的评价;但是，这些特征非常有机地融合在一起。
在进行懒惰评估时，通常会想到 memoization 。虽然自动执行是一个很难（可能仍未解决）的问题，有很多细节和陷阱。
所以，基本上，如果你更深入地看待它，每个方面都有可能性和权衡取舍;您作为软件工程师的任务是了解所有这些并根据具体问题细节明智地选择。