什么时候变得更好？

什么时候使用懒惰评估而不是渴望评估更好？当你知道表达式只计算一次，或者从不计算时，它会更好吗？什么时候变得更好？

2014-05-05 geekybedouin

这是很难说的一般，至少在任何有用的方式。这取决于语言和任务。 – Chuck

@Chuck有我在我的答案中链接到的这篇着名的文章，这是一个普遍的论点... –

@WillNess：我已阅读为什么函数式编程很重要，只是再次刷新它来刷新我的记忆，我不认为它包含这个问题的一个很好的答案。它解释了普遍惰性评估的一些普遍优势，但AFAIK并没有探讨懒惰与严格评估之间的实际权衡，或者如何评估在给定情况下哪种方法更好用（例如，在Haskell中，有一整类通过切换到严格评估而消除的问题）。我同意这篇文章的启发性和相关性，但它并没有真正回答这里提出的问题。 – Chuck

如果您有选择，请对表达式使用懒惰评估，这些表达式可能根本无法评估，或者在评估时可能会在某些情况下导致编程错误。

经典的例子是在大多数语言由C降实现，被称为“短路运营商”：

if (i != 0 && n/i > 100) ...

这里，当i不为0，这是很好n/i > 100才会被计算，因为它避免零分割错误。

来源

2014-05-05 10:34:41 Ingo

更基本的例子是，如果作为一个特殊的声明，你不需要，但如果你通过“then”和“else”参数的thunk，你可以将它作为一个标准函数来实现。那么当然你需要一些原始的来选择哪一个被评估，这可以被解决，例如，通过布尔多态性（这是例如SmallTalk的情况） –

Why Functional Programming Matters是支持懒惰评估的典型论据，主要作为改进模块化的促进者。

我可以通过埃拉托塞尼的筛您提供作为一个例子为素数懒惰制剂，

primes = (cons 2 . diff [3..] . bigU . map (\p-> [p*p, p*p+p..])) primes

（.）是函数的组合物，diff是一组差异，bigU发现的（有序的）列表的并集（有序的，增加的）数字列表，map是map等....，没有惰性语义将不得不将maintain all kinds of mechanics explicitly混合在一起，而不是使用这些好的独立模块函数与函数组合链接在一起。

来源

2014-05-05 22:16:22

什么时候变得更好？

回答

相关问题