“Lisp-1 vs Lisp-2”与静态类型的语言相关吗？

Question

（这是一个 CS 理论类型的问题；我希望这是可以接受的。）

“Lisp-1 vs Lisp-2”的争论是关于函数的命名空间是否应该与所有其他变量的命名空间不同，这与允许程序员将函数作为值传递的动态类型语言相关。 Lisp-1 语言（例如 Scheme）有一个命名空间，所以你不能同时拥有一个名为 f 的函数和一个名为 f 的整数（一个会影响另一个，就像两个名为 f 的整数一样） . Lisp-2 语言（例如 Common Lisp）有两个命名空间，所以你可以同时拥有 f 变量，但你必须用特殊语法指定你的意思（#'f 是函数，f 是整数)。

在我看来，如果语言也是静态类型的（与大多数 Lisps 不同），主要的技术问题，即消除函数与整数的歧义的需要不是问题。例如，如果 sort 函数需要一个列表和一个小于函数作为显式签名，

def sort[X](list: List[X], lessThan: Function[X, Boolean])    // Scala syntax; had to pick something

那么函数和其他所有内容是否在同一个命名空间中都没有关系。如果myless 是一个函数，sort(mylist, myless) 只会通过类型检查——不需要特殊语法。有人认为一个命名空间比两个命名空间更美观，但我想重点关注技术问题。

假设所讨论的语言是静态类型的，两个命名空间是否会变得更困难或更容易出错（或者相反，对于一个命名空间而言）？

（我在我正在研究的领域特定语言的背景下考虑这个问题，我想确保我不会在未来遇到问题。用它来实现会更容易两个命名空间（Lisp-2），因为它是静态类型的，所以不需要#'f。知道要问。）

Answer 1

对多个命名空间的一个非常常见的反对意见是，它使形式语义复杂化以具有任意数量的命名空间。一个命名空间使事情变得简单。下一个最简单的，所以我被告知（我不写这些东西），是无限数量的命名空间——我尝试过一次但只完成了一半（see here if curious，虽然我认为这不是你的'在这种情况下要求）。当你将它限制在有限数量的命名空间中时，形式语义就会变得混乱，或者我被告知。当然，它也使任何类型的编译器或解释器变得更加复杂。这种反对跨越美学和技术，因为它不是基于技术难度本身的反对，因为不需要超人的智慧来做多个命名空间，只是需要大量额外的体力劳动，而是反对做一个更复杂的语义意味着更多的代码，更多的特殊情况，更多的错误机会等。就我个人而言，我不会被这些论点所左右，我只是在你问的时候指出它们。我想你会发现这样的论点并不是致命的，继续你正在做的事情并看看它会导致什么是很好的。我更关心程序员/最终用户的体验，而不是实现者的难度。但我提到这个论点是因为我尊重的其他人似乎认为这是一件大事，我相信这是对你关于难度和容易出错的问题的正确答案。

请注意，顺便说一下，当 Gabriel 和我写 Technical Issues of Separation in Function Cells and Value Cells 时，我需要一些词来帮助我避免说“Scheme-like”和“Lisp-like”，因为人们有不相关的理由偏爱 Scheme，而这些理由毫无意义。使用命名空间。使用“Lisp1”和“Lisp2”这两个术语让我避免了这篇论文成为一场 Scheme 与 Lisp 的争论，并将读者的注意力集中在命名空间的问题上。最后，ANSI Common Lisp 至少有 4 个命名空间（函数、值、go 标签、块标签），如果计算类型（在某些方面有点像命名空间，但在其他方面不是），可能有 5 个，但在任何情况下都不是 2。所以严格来说它将是 Lisp4 或 Lisp5。但无论哪种方式，它仍然让那些喜欢单一命名空间的人感到恐惧，因为任何大于 1 的任意有限数对他们来说都是不可接受的。

我个人的建议是你应该根据你个人对正确的感觉来设计语言。对于某些语言，一个命名空间就可以了。对于其他人没有。只是不要这样做，因为有人告诉你任何一种方式都必须是正确的方式——这确实是你的选择。

有些人认为一个命名空间在概念上更简单，但我认为这取决于简单的概念。有人说更小更简单（在符号上或实现上）。我声称概念上最简单的东西与你的大脑对事物的看法最同构，而且你的大脑可能并不总是以“小”为“简单”。我至少举一个例子，现有的每一种人类语言对同一个词都有多个定义，几乎都由上下文解决（您的类型推断可能是上下文信息的一个例子），这表明湿件旨在消除歧义这样的事情，如果你不让它关心这些事情，你的大脑就会浪费它的一些自然能力。也许确实这种上下文推断增加了语言实现的复杂性，但语言只实现一次，并且被多次使用，因此完全有理由优化最终用户体验，而不是实现者体验。这是一项以后会有回报的投资。

坚持按照自己的意愿思考事情。更多地担心让你的语言有良好的感觉，以及你想做的事情是否完全可以实现，即使它确实需要工作和额外的代码检查。没有一种语言设计决策对每种语言都是正确的——语言是生态系统，重要的是语言元素相互配合良好，而不是语言元素与其他语言匹配。事实上，如果语言都一样，那么拥有多种语言将毫无意义。