据我所知，Racket有严格的评价，但可以选择懒惰的评价。我在函数式语言上所做的有限阅读表明，懒惰的评估语言通常更具表现力，因此在选择所有Racket程序的延迟评估选项时存在任何“技术”缺点（在速度，代码的健壮性，存在方面）图书馆等...）？
如果没有，是否有明确的哲学理由倾向于严格评估（参考文献被接受）？
答案 0 :(得分：4)
如果您对不同语言的表达感兴趣，那么我可以推荐Matthias Felleisen撰写的“关于编程语言的表达能力”。摘要：
关于编程语言的文献包含大量的非正式语言 声称相对表达能力 编程语言，但没有形式化这样的框架 陈述或产生有趣的后果。作为第一步 在这个方向上，我们形成了一种表达性和形式的正式概念 调查其属性。为了验证理论，我们分析了一些 广泛持有关于几个人的表达能力的信念 功能语言的扩展。基于这些结果，我们相信 我们的系统正确地捕获了许多非正式的想法 在表达方面，它构成了进一步的基础 研究这个方向。
答案 1 :(得分：1)
如果没有某种伴随的严格性分析，默认的懒惰语言是不切实际的，因为懒惰的评估会导致资源开销，而这往往会抵消它的好处。您可以通过在#lang lazy中玩游戏来看到这一点，#lang lazy是Racket附带的概念验证懒惰语言。除了最小的玩具程序之外，delay太慢而无法使用。
理想情况下，我们会使用某种混合懒惰严格的语言，在有益的时候使用懒惰，但在其他方面要严格避免浪费资源，但是找出懒惰或严格的最佳平衡仍然是一个悬而未决的问题。可以说，过去几十年来Haskell社区开展的大量研究都是为了对抗懒惰，试图找到这种平衡，这并不是一件容易的事。在Haskell邮件列表或SO主题上，您经常会发现一个程序员试图为他们的程序添加“太懒”的严格程度。
球拍有force和{{1}}，您可以根据需要使用它来充分利用懒惰，而不是在不需要时支付开销。然而，可能有一些习惯用惰性语言更容易推理，比如“打结”。
支持严格第一种方法的一点是，大多数关于混合懒惰严格方法的研究发现，大多数时候，你只需要少量的懒惰。例如，请参阅this paper on Optimistic Evaluation。