95

注意：我不是在问要学哪个，哪个更好，或者类似的东西。

我选择了 SICP 的免费版本，因为我觉得它读起来会很好（我听说过关于它的好东西，而且我对这种编程方面很感兴趣）。

我知道 Scheme 是 Lisp 的一种方言，我想知道：Scheme 和 Common Lisp 之间的实际区别是什么？

似乎有很多关于“CL 有一个更大的标准库......方案不适合现实世界的编程......”但没有实际的东西说“这是因为 CL 是这个/有这个”。

4

4 回答 4

116

这是一个有点棘手的问题，因为差异既是技术上的，也是（更重要的是，在我看来）文化上的。答案只能提供一种不精确的、主观的观点。这就是我要在这里提供的。有关一些原始技术细节，请参阅Scheme Wiki。

Scheme是一种建立在提供优雅、一致、深思熟虑的基础语言基础的原则的语言，实用和学术应用语言都可以在此基础上构建。

您很少会发现有人用纯 R5RS（或 R6RS）Scheme 编写应用程序，并且由于极简标准，大多数代码不能跨 Scheme 实现移植。这意味着如果您想编写某种最终用户应用程序，您将必须仔细选择您的 Scheme 实现，因为选择将在很大程度上决定您可以使用哪些库。另一方面，设计实际应用程序语言的相对自由度意味着 Scheme 实现通常提供其他地方闻所未闻的功能。例如，PLT Racket 使您能够使用静态类型并提供了一个非常具有语言感知能力的 IDE。

基础语言之外的互操作性是通过社区驱动的 SRFI 流程提供的，但任何给定 SRFI 的可用性因实施而异。

大多数 Scheme 方言和库都专注于函数式编程习惯用法，例如递归而不是迭代。当您想要执行 OOP 时，可以将各种对象系统作为库加载，但是与现有代码的集成在很大程度上取决于 Scheme 方言及其周围的文化（例如，Chicken Scheme 似乎比 Racket 更面向对象）。

交互式编程是 Scheme 子社区的另一个不同点。MIT Scheme 以强大的交互性支持而闻名，而 PLT Racket 感觉更静态。无论如何，交互式编程似乎并不是大多数 Scheme 子社区的核心关注点，而且我还没有看到与大多数 Common Lisps 具有类似交互性的编程环境。

Common Lisp是一种为实际编程而设计的久经考验的语言。它充满了丑陋的缺陷和兼容性技巧——与 Scheme 优雅的极简主义完全相反。但它本身也更具特色。

Common Lisp 孕育了一个相对庞大的可移植库生态系统。您通常可以随时切换实现，即使是在应用程序部署之后，也不会太麻烦。总体而言，Common Lisp 比 Scheme 更加统一，而且更激进的语言实验，如果完成的话，通常作为可移植库嵌入，而不是定义全新的语言方言。正因为如此，语言扩展往往更保守，但也更可组合（并且通常是可选的）。

通用语言扩展（如外部函数接口）不是通过正式方式开发的，而是依赖于所有主要 Common Lisp 实现中可用的准标准库。

语言习语是函数式、命令式和面向对象方法的混合体，总的来说，Common Lisp 感觉更像是一种命令式语言而不是函数式语言。它也非常动态，可以说比任何流行的动态脚本语言都更动态（例如，类重新定义适用于现有实例，并且条件处理系统具有内置的交互性），并且交互式探索性编程是其重要组成部分“Common Lisp 方式。” 这也反映在 Common Lisp 可用的编程环境中，实际上所有这些环境都提供了与正在运行的 Lisp 编译器的某种直接交互。

Common Lisp 具有一个内置对象系统 (CLOS)、一个比单纯的异常处理强大得多的条件处理系统、运行时可修补性以及各种内置数据结构和实用程序（包括臭名昭著的LOOP宏、迭代子语言对于 Scheme 来说太丑了，但太有用了，更不用说，还有一个类似 printf 的格式化机制，在格式字符串中支持 GOTO ）。

由于基于图像的交互式开发，以及更大的语言，Lisp 实现在操作系统之间的可移植性通常低于 Scheme 实现。例如，让 Common Lisp 在嵌入式设备上运行并不适合胆小的人。与 Java 虚拟机类似，您也往往会在虚拟内存受限的机器（如基于 OpenVZ 的虚拟服务器）上遇到问题。另一方面，方案实现往往更加紧凑和便携。ECL 实施质量的提高在一定程度上缓解了这一点，尽管其本质仍然是正确的。

如果您关心商业支持，有几家公司提供他们自己的 Common Lisp 实现，包括图形 GUI 构建器、专用数据库系统等。

综上所述，Scheme 是一种设计更优雅的语言。它主要是一种具有一些动态特性的函数式语言。它的实现代表了具有鲜明特征的各种不兼容的方言。Common Lisp 是一种成熟的、高度动态的、多范式的语言，具有各种丑陋但实用的特性，其实现在很大程度上相互兼容。与 Common Lisp 相比，Scheme 方言往往更静态且交互性更低；Common Lisp 实现往往更重且更难安装。

无论您选择哪种语言，我都希望您玩得开心！:)

于 2011-03-20T23:54:50.787 回答
24

一些基本的实际差异：

  • Common Lisp 对变量和函数有不同的作用域；而在Scheme中只有一个范围——函数是值，定义一个具有特定名称的函数只是定义一个设置为lambda的变量。因此，在 Scheme 中，您可以将函数名称用作变量并将其存储或传递给其他函数，然后像调用函数一样使用该变量执行调用。但是在 Common Lisp 中，您需要使用 将函数显式转换为值(function ...)，并使用 显式调用存储在值中的函数(funcall ...)
  • 在 Common Lisp 中，nil（空列表）被认为是假的（例如 in if），并且是唯一的假值。在 Scheme 中，空列表被认为是 true，并且（distinct）#f是唯一的 false 值
于 2011-03-22T07:27:54.517 回答
10

这是一个很难公正回答的问题，尤其是因为许多 LISP 人员会将 Scheme 归类为 LISP。

Josh Bloch（这个类比可能不是他的发明）将选择语言描述为类似于选择当地酒吧。鉴于此，那么：

“Scheme”酒吧里有很多编程语言研究人员。这些人非常关注语言的含义，保持其定义明确和简单，并讨论创新的新功能。每个人都有自己的语言版本，旨在让他们探索自己特定的编程语言角落。Scheme 的人真的很喜欢他们从 LISP 中得到的带括号的语法。它灵活、轻量且统一，消除了语言扩展的许多障碍。

“LISP”酒吧？嗯……我不应该评论；我没有花足够的时间在那里:)。

于 2011-03-20T18:52:34.653 回答
2

方案：

  • 最初很少有规格（新的 R7RS 似乎更重）
  • 由于语法简单，可以快速学习方案
  • 实现提供了额外的功能，但名称在不同的实现中可能不同

常见的口齿不清：

  • 许多功能由更大的规范定义
  • 函数和变量的不同命名空间（lisp-2）

这是一些要点，当然还有更多，我现在不记得了。

于 2011-03-20T14:32:39.070 回答