是"Lisp-1 vs Lisp-2"吗?与具有静态类型的语言相关吗? [英] Is "Lisp-1 vs Lisp-2" relevant in a language with static types?

问题描述

(这是CS理论的问题；我希望可以接受.)

(This is a CS-theory type of question; I hope that's acceptable.)

" Lisp-1 vs Lisp-2 的辩论是有关函数的名称空间是否应与所有其他变量的名称空间区分开的问题，并且与动态类型的语言有关，这些语言允许程序员将函数作为值传递. Lisp-1语言(例如Scheme)具有一个名称空间，因此您不能同时拥有一个名为f的函数和一个名为f的整数(一个会隐藏另一个，就像两个名为f的整数一样) . Lisp-2语言(例如Common Lisp)具有两个名称空间，因此您可以同时具有两个f变量，但是必须指定使用特殊语法表示的变量(#'f是函数，f是整数) ).

The "Lisp-1 vs Lisp-2" debate is about whether the namespace of functions should be distinct from the namespace of all other variables, and it's relevant in dynamically typed languages that allow the programmer to pass around functions as values. Lisp-1 languages (such as Scheme) have one namespace, so you can't have both a function named f and also an integer named f (one would shadow the other, just like two integers named f). Lisp-2 languages (such as Common Lisp) have two namespaces, so you can have both f variables, but you have to specify which one you mean with special syntax (#'f is the function and f is the integer).

在我看来，如果语言也是静态类型的(与大多数Lisps不同)，则主要的技术问题(将函数与整数进行歧义的需求)就不是问题.例如，如果sort函数需要一个列表和小于函数作为显式签名，

It seems to me that the main technical problem, the need to disambiguate the function from the integer, is not an issue if the language is also statically typed (unlike most Lisps). For instance, if a sort function requires a list and a less-than function as an explicit signature,

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

然后，函数和其他所有功能是否都位于同一命名空间中并不重要.如果myless是函数，则sort(mylist, myless)仅通过类型检查-不需要特殊的语法.有人认为，一个命名空间比两个命名空间在美学上更令人愉悦，但我想着重于技术问题.

then it wouldn't matter if the functions and everything else are in the same namespace or not. sort(mylist, myless) would only pass a type check if myless is a function--- no special syntax needed. Some people argue that one namespace is more aesthetically pleasing than two namespaces, but I'd like to focus on technical issues.

如果假设所讨论的语言是静态类型的，那么两个命名空间是否会使难度更大或更容易出错(或者相反，对于一个命名空间而言)呢?

(我正在我正在使用的领域特定语言的背景下考虑这个问题，我想确保自己不会遇到麻烦.使用它会更容易实现两个命名空间(Lisp-2)，并且由于它是静态类型的，因此不需要等价于#'f的问题.知道要问.)

(I'm thinking about this in the context of a domain specific language that I'm working on, and I want to make sure that I don't run into problems down the road. It would be easier to implement with two namespaces (Lisp-2), and since it's statically typed, there's no need for the equivalent of #'f. I asked the question in general because I want to hear general points and perhaps become aware of questions that I don't yet know to ask.)

推荐答案

对多个名称空间的一种非常普遍的反对意见是，它使形式语义复杂化，无法拥有任意数量的名称空间.一个名称空间使事情变得简单.我被告知，下一个最简单的事情是(我不写这些东西)，它是无限数量的命名空间-我曾经尝试做一次，但只完成了一半(

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.

请注意，顺便说一句，当我和加布里埃尔(Gabriel)撰写分离的技术问题时，在功能单元格和值单元格中，我需要一些单词来帮助我避免说类似于方案"和类似于Lisp"，因为人们倾向于使用与命名空间无关的Scheme，这是无关紧要的.使用术语"Lisp1"和"Lisp2"使我避免了将本文变成"Scheme vs. Lisp"辩论，并且使读者仅关注命名空间问题.最后，ANSI Common Lisp最终至少包含4个名称空间(函数，值，go标记，块标记)，或者如果您计算类型(某种程度上类似于名称空间，但不包括其他名称空间)则可能为5.无论如何，都不是2.因此严格来说，它应该是Lisp4或Lisp5.但是，无论哪种方式，它仍然使那些偏爱单一名称空间的人感到恐惧，因为任何大于1的任意有限数字都将被他们接受.

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.

这篇关于是"Lisp-1 vs Lisp-2"吗?与具有静态类型的语言相关吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！