我很好奇静态类型和懒惰函数语言之间的关系。例如，是否可以使用动态惰性函数语言？好像所有懒惰的函数式语言都是静态类型的（Haskell，Miranda等），并且所有动态函数语言都使用严格的评估（Clojure，Scheme等）。
特别是，Lazy评估的Wikipedia article显示为：
但是，懒惰的评价，很难与之结合 必要的功能，例如异常处理和输入/输出， 因为操作的顺序变得不确定。懒惰的评价 可以引入空间泄漏。
静态类型在防止空间泄漏方面起什么作用？
答案 0 :(得分：14)
我认为静态类型根本不起作用。例如，考虑无类型的惰性语言Lazy Racket。我没有听到任何迹象表明它以Haskell（例如）没有的方式泄漏空间。
另一方面，副作用是的一个问题，因为人类发现严格评估的评估顺序是（相对）自然的，并且需要的呼叫更难以进行心理预测
答案 1 :(得分：6)
静态类型在防止空间泄漏方面起什么作用？
类型可用于跟踪对象的生命周期，静态地确保没有泄漏。
一个例子是区域类型和其他效果类型。
答案 2 :(得分：3)
懒惰评估和静态类型是独立的概念。
粗略地说，评估是程序运行时发生的事情。 打字是在编译程序时发生的事情。
但当然，打字系统和评估策略之间存在重要的对应关系：
如果术语 M 减少为 N 且 M：σ（ M 属于 σ）然后 N：σ。
这意味着当我们运行某个类型为σ的程序时，则为该值 将具有相同的类型。没有这个属性，打字系统确实如此 没用（至少对编程而言）。这也意味着一旦我们输入了一个 在编译过程中，我们不需要记住输入信息 在评估它时，因为我们知道结果将具有正确的类型。
关于您引用的维基百科文章。有两件事：
势在必行。这与打字系统无关。问题是，如果在惰性设置中评估某些表达式有副作用（如大多数语言中的I / O），则很难预测何时（如果有的话）发生副作用。因此，一旦你进行了懒惰的评估，就很难有一种不纯洁的语言。
一个例外是 Clean语言。它使用特殊类型系统来处理懒惰设置中的副作用。所以这里通过处理副作用在评估策略和打字系统之间存在一些联系：类型系统允许以这样的方式处理副作用，以便我们可以保持懒惰的评估。
答案 3 :(得分：2)
我认为如果从更一般的层面看事物，就可以观察到静态类型和惰性函数语言之间的自然关系。静态类型的要点是通知和提升编译器的功能;通过调查语言之间的静态 - 动态鸿沟，它通常会跟踪编译代码和解释代码之间的分歧。
懒惰评估的重点是什么？
Peyton-Jones等人的一篇臭名昭着的回顾性文章将懒惰的评价描述为“头发衬衫”，它使语言保持纯粹的功能。他的比喻恰当地传达了哈斯克尔社区根深蒂固的指称语义理想主义。非严格评估的基本好处是它以促进这种指称范式的方式转换构造代码的可能性。在Bob Harper和Haskell社区进行的臭名昭着的懒惰评估辩论中，Harper教授展示了懒惰评估对实际项目的挑战 - 在Lennart Augustsson的懒惰防御中，这一点最能说明这一点：
“我已经保存了我最后一次严格评估的抱怨。严格的评估对功能重用有根本的缺陷。[...]通过严格的评估你不能再直面告诉别人：不要使用递归在地图，过滤器，折叠器等中重复使用递归模式。它根本不起作用（通常）。[...]严格的评估确实，从根本上阻止你以懒惰的方式重复使用功能。“
对于他通过延迟评估重用函数的例子，Augustsson提供了“通过重用any和map函数来表达or函数是很自然的。< / em>“因此，从这张图片中可以看出，懒惰的评价是一种相当昂贵的语言特征，包含在更自然的编码风格中。
我们还需要什么才能维持抽象的，指称式的编码风格？强大的优化编译器可能会派上用场！因此，即使静态类型和惰性评估之间没有技术或必要的连接，这两个特征也面向相同的目标。他们经常一起出现并不令人惊讶。