（这是问题的一个CS-理论型，我希望这是可以接受的。）
在“ Lisp的1对Lisp的-2 ”的争论是关于函数的命名空间是否应该从所有其他变量的命名空间不同，它是在动态类型语言，允许程序员功能绕过作为值相关。 Lisp的1种语言（如Scheme）有一个命名空间，所以你不能有两种功能：一个名为f也整数命名f （一会影另一方面，就像两个整数命名f ）。 Lisp的2种语言（如Common Lisp的）有两个命名空间，所以你可以有两种f变量，但你必须指定你的意思是用特殊的语法其中之一（ #'f是功能和f是整数）。
在我看来，主要的技术问题，需要从整数歧义的功能，是不是一个问题，如果语言也静态类型（不像大多数的Lisp）。 举例来说，如果一个sort功能需要一个列表和小于号功能明确的签名，
def sort[X](list: List[X], lessThan: Function[X, Boolean]) // Scala syntax; had to pick something
那么如果其他的功能，一切都在同一个命名空间或不将没有关系。 sort(mylist, myless)如果只传递一个类型检查myless是一个功能---不需要特殊的语法。 有些人认为，一个命名空间比两个命名空间更美观，但我想专注于技术问题。
有什么，两个名字空间将使（一个命名空间或反之）更困难或更多容易出错，假定所涉及的语言静态类型？
（我想这个在我工作的一个领域特定语言的背景下，我想确保我没有碰上的道路问题。这将是更容易了两个命名空间来实现（ Lisp的-2），由于它是静态类型，没有必要为相当于#'f我问的问题一般是因为我想听到的一般点或许意识到，我还不知道要问的问题。）
One very common objection to multiple namespaces is that it complicates the formal semantics to have an arbitrary number of namespaces. One namespace makes things simple. The next simplest, so I'm told (I don't write these things), is an infinite number of namespaces--something I tried to do once and only got halfway through (see here if curious, though I think it's not what you're asking for in this case). It's when you limit it to a finite number of namespaces that a formal semantics gets messy, or so I'm told. And certainly it makes any kind of compiler or interpreter a bit more complex, too. This objection straddles between aesthetic and technical in that it's not an objection based on technical difficulty per se, as no super-human intelligence is required to do multiple namespaces, just a lot of extra manual labor, but rather an objection that doing a more complex semantics means more code, more special cases, more chances for error, etc. Personally, I'm not swayed by such arguments, I merely point them out since you ask. I think you'll find such arguments aren't fatal and that it's fine to proceed on what you're doing and see where it leads. I care much more about programmer/end-user experiences than implementor difficulty. But I mention this argument because other people I respect seem to think this is a big deal and I believe it's the correct answer to your question about difficulty and error-prone-ness.
Note, by the way, that when Gabriel and I wrote Technical Issues of Separation in Function Cells and Value Cells, I needed words to help me avoid saying "Scheme-like" and "Lisp-like" because people had unrelated reasons for preferring Scheme that had nothing to do with namespacing. Using the terms "Lisp1" and "Lisp2" allowed me keep the paper from becoming a Scheme vs. Lisp debate, and to focus readers narrowly on the matter of namespace. In the end, ANSI Common Lisp ended up with at least 4 namespaces (functions, values, go tags, block tags) or maybe 5 if you count types (which are sort of like a namespace in some ways but not others), but in any case not 2. So strictly it would be a Lisp4 or Lisp5. But either way it still horrifies those who prefer a single namespace because any arbitrary finite number bigger than one tends to be unacceptable to them.
My personal recommendation is that you should design the language according to your personal sense of what's right. For some languages, one namespace is fine. For others not. Just don't do it because someone tells you that either way has to be the right way--it's really legitimately your choice to make.
Some argue that one namespace is conceptually simpler, but I think that depends on the notion of simplicity. Some say smaller is simpler (notationally or implementationally). I claim that what's conceptually simplest is what's most isomorphic to how your brain thinks about things, and that your brain may not always be thinking "small" for "simple". I'd cite as at least one example that every human language in existence has multiple definitions for the same word, almost all resolved by context (of which your type inferencing might be one example of contextual information), suggesting that wetware is designed to disambiguate such things and that your brain is wasting some of its natural capacity if you don't let it care about such things. Maybe indeed this contextual inferencing increases the complexity of your language implementation, but languages are implemented only once, and are used many times, so there's every reason to optimize the end user experience, not the implementor experience. It's an investment that pays off later.
Insist on thinking about things how you want. Worry more about making your language have a good feel and about whether what you want to do is implementable at all, even if it does require work and extra checking of the code. No language design decision is the right one for every language--languages are ecologies and what matters is that language elements work well with one another, not that language elements match other languages. Indeed, if languages were going to be all the same, it would be pointless to have multiple languages.
