在具有静态类型的语言中，"Lisp-1 vs Lisp-2“是否相关？

Question

(这是一个CS理论类型的问题，我希望这是可以接受的。)

"Lisp-1对Lisp-2“争论的问题是函数的命名空间是否应该与所有其他变量的命名空间不同，并且在动态类型语言中与此相关，这些语言允许程序员将函数作为值传递。Lisp-1语言(如Scheme)有一个名称空间，因此您不能同时拥有一个名为f的函数和一个名为f的整数(其中一个将隐藏另一个整数，就像两个名为f的整数)。Lisp-2语言(如Common )有两个名称空间，因此您可以拥有两个f变量，但您必须用特殊的语法指定其中的一个(#'f是函数，f是整数)。

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

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

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

假设所讨论的语言是静态类型的，两个名称空间是否会使错误更加困难或更容易出错(或者相反，对于一个命名空间)？

(我是在我正在研究的一种特定领域语言的背景下考虑这个问题的，我想确保我不会在今后遇到问题。)使用两个名称空间(Lisp-2)更容易实现，而且由于它是静态类型的，因此不需要类似于#'f。我一般问这个问题，是因为我想听一般性的观点，也许会意识到我还不知道要问的问题。)

Answer 1

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

顺便说一句，当加布里埃尔和我写功能细胞与价值细胞分离的技术问题的时候，我需要一些词来帮助我避免说" Scheme -like“和"Lisp-like”，因为人们选择与名称空间无关的方案是没有关系的。使用"Lisp1“和"Lisp2”这两个术语，我就可以避免论文变成一场针对Lisp的辩论，并将读者狭隘地集中在命名空间的问题上。最后，至少有4个名称空间(函数、值、go标记、块标记)，或者可能有5个类型(在某些方面类似于名称空间，而不是其他方式)，但在任何情况下都不是2。所以严格来说，它将是一个Lisp4或Lisp5。但无论哪种方式，它仍然令那些喜欢使用单一名称空间的人感到恐惧，因为任何大于一个名称空间的任意有限数都是他们无法接受的。

我个人的建议是，你应该根据你个人对什么是正确的感觉来设计语言。对于某些语言来说，一个名称空间是可以的。对其他人来说不是。但不要这样做，因为有人告诉你，任何一种方式都必须是正确的--这是你真正合理的选择。

有些人认为，一个名称空间在概念上更简单，但我认为这取决于简单性的概念。有人说更小更简单(无论是在名义上还是在实现上)。我声称，在概念上最简单的是，什么是与你的大脑对事物的看法最相似的东西，而你的大脑可能并不总是认为“小”而不是“简单”。我至少举一个例子说明，现存的每一种人类语言对同一个词都有多个定义，几乎所有的定义都是由上下文来解决的(你的类型推断可能就是上下文信息的一个例子)，这意味着wetware的设计是为了消除这类事物的歧义，如果你不让它关心这些事情，那么你的大脑就是在浪费它的一些自然能力。也许这种上下文推理确实增加了语言实现的复杂性，但语言只实现了一次，并且多次使用，因此有充分的理由优化最终用户体验，而不是实现者体验。这是一项后来得到回报的投资。

坚持想你想要的东西。更多地担心如何让您的语言有一个良好的感觉，以及您想要做的事情是否是可实现的，即使它确实需要工作和额外的代码检查。没有一种语言设计决定是正确的--语言是生态的，重要的是语言元素能很好地相互配合，而不是语言元素与其他语言相匹配。事实上，如果所有语言都是相同的，那么使用多种语言是毫无意义的。