各种 ANSI CL 实现有何不同？答案

【问题标题】：How do the various ANSI CL implementations differ?各种 ANSI CL 实现有何不同？
【发布时间】：2010-10-09 03:00:31
【问题描述】：

当我开始从 Practical Common Lisp 学习 CL 时，正如书中所宣传的那样，我从 Allegro CL 编译器开始。我停止使用它，因为它的商业性，但免费的部分并没有给我留下深刻印象。它需要连接到其远程服务器以获取一些许可。

我切换到“clisp”并正在使用它。现在，我听说了 SBCL，也打算开始使用它。

所以，问题是：各种 ANSI CL 实现有何不同？有任何使用其中一个的实际经验吗？

谢谢。

【问题讨论】：

标签： lisp common-lisp

【解决方案1】：

参见 Daniel Weinreb 的 Common Lisp Implementations: A Survey。

【讨论】：

谢谢，我会处理的。

【解决方案2】：

如果您在可以运行 SBCL 的机器上，您应该使用它。它是最快的免费 Lisp 编译器（它可以生成同样快的代码作为 Haskell、OCaml、Java、C 和 C++，它们都非常非常快，特别是与 Python 和 Ruby 相比）。它也是一个相当完整的实现，并支持 Swank 的大部分功能（用于 SLIME），这在您开发时非常有用。

正如其他一些 cmets 所提到的，您不会真正注意到任何刚开始时的差异。所有免费的CL 实现“足够快”并支持您需要的所有功能。但如果你开始写作制作软件，您将欣赏 SBCL 的功能。 OTOH，现在真的没有理由不切换。

【讨论】：

谢谢，我刚换了。
SBCL的REPL比clisp难用。
@jrockway - 这个建议在 2012 年仍然有效吗？
最近CL写的不多，但是SBCL对我来说还是够用了。
CLISP 通常会配置 readline 支持，而 SBCL 不支持。如果使用rlwrap 运行SBCL 的REPL（从命令行），它会得到很大改进，它使用readline 来执行类似的功能。使用 SLIME 运行时，我没有注意到易用性方面的任何差异。如果这不是@z_axis 的意思，那么也许他可以提供更多细节。除此之外，repl-utilities 可以让任何 REPL 变得更好。现在我再次阅读了 cmets，我看到查理正在和 jrockway 交谈......无论如何，我的评论仍然有效。

【解决方案3】：

我一直在寻找相同问题的 Win32 解决方案。至于 Windows 上的免费 Lisp 实现，我强烈推荐 Clozure CL (CCL)。有几个原因。首先是 Clozure 支持 32 位和 64 位二进制文件。它非常快，而且有点紧凑。但最重要的是，它是一致且正确的。在与 Lispworks（我很怀念）合作了几年之后，我发现它是一个非常成熟的 Lisp。 CCL 在本机操作系统线程、套接字和其他一些不属于 CL 规范的元素方面做得非常好。它对CLOS的实现似乎非常彻底。它的 GC 和内存管理非常出色。我将 CCL 与 Win32 上的 SBCL 进行了比较，虽然 SBCL 在几个基准测试中要快一些，但它的缺点更多，而且它的形象不断增长，即使在几次强制 GC 之后也是如此。同时，CCL 始终如一、小巧、快速且易于使用。如果您想要一个在 Windows、Mac 和 Linux 上保持一致并且同时支持 32 位和 64 位的平台，那就别无所求。

我确实在 Win32 上尝试过 CormanLisp，其中有很多我喜欢的地方。但它不能在 64 位 Windows 平台上正常运行，并且仅限于 Win32。它也不是免费的，当我向它扔一些垃圾代码时，不知何故我让它崩溃了。我也很容易让 SBCL 崩溃。 CCL 并非如此。坚如磐石。真的，这些人做得非常出色，最终将帮助 Lisp 保持活力。

至于 SLIME，我并没有尝试让 SLIME 与 SBCL 一起工作，但我确实让它与 CCL 很好地工作。无论您喜欢什么，我都建议人们编写易于移植的代码。目标是 Windows、Mac 和 Linux，目标是 64 位。如果您考虑到这些，那么总体而言，CCL 是您的最佳选择。

最后一次尝试解决这个问题是考虑其他问题的问题。这是我找到的：

CLISP 很好，但相对于 SBCL 或 CCL，速度要慢得多。我看不到任何好处
SBCL 在 Win32 上似乎很差。图片尺寸可能会变大。
CormanLisp 在 Win32 上很好，但不便携，并且不支持 Windows x64。 Roger Corman 似乎也没有积极开发 CormanLisp，这是很遗憾，但这就是现实。
Clojure（带有“j”）不是 Common Lisp。尽管它可能很好，但我认为如果你已经了解 CL，那么学习 Clojure 的开销是不值得的许多差异。我敢肯定有些人可能会很快把它们捡起来，但我肯定没有。（如果您追求的是与 Java 兼容的代码，那么请查看 ABCL）。

戴夫

【讨论】：

不能更同意 Windows 上的 CCL（x86 或 x86_64）。它的另一个好处是它在 linux、mac、BSD 和 solaris 上也运行得非常好，所以你可以真正编程一次，几乎可以在任何地方运行。我倾向于在 windows 中开发并将我的代码推送到 linux 服务器。使用 CCL 执行此操作绝不会遇到问题。

【解决方案4】：

ANSI CL 的某些部分将某些细节留给实现来确定；您会发现对于标准的这些部分，每个实现都有自己的怪癖。

此外，寻找对运行时重要但未在语言中定义的内容：线程和多处理以及垃圾收集等内容在性能和可靠性方面会有很大差异。

我发现 SBCL 是在 Linux 中最容易使用的实现；它对 Linux 中的线程有很好的支持。关于垃圾收集器我不能说太多，因为它对我来说还不是很重要。

在 Windows 上，您最好的选择可能是 Allegro 或 LispWorks，尽管我在 Windows 上使用 clisp 取得了一些成功。 SBCL的Windows移植正在进步，但我用的不多，所以不能评论。

一般来说，对这类事物的理解是通过研究或分析难以获得的；它来自经验。只需选择一个您感到满意的体面实现，然后开始工作。您会在进行过程中找出棘手的问题。

【讨论】：

【解决方案5】：

我没有足够的知识来给你一个详细的答案，但是当我在我的 AI 课程中使用 CL 时，我注意到 SBCL 比 Clisp 快得多。除非您有令人信服的理由不这样做，否则我建议您选择 SBCL。

我听说 Clisp 比 SBCL 更容易安装并且更便携（它有很多针对处理器的优化），但是如果您使用的是 Linux，它们都可以很容易地从包管理器中获取。

【讨论】：

我知道的不多，但我很难过你没有得到答案。希望我提供的一点帮助！
SBCL 编译为本机代码，clisp 编译为字节码，然后由 clisp 虚拟机解释。这就是您提到的速度和便携性问题的根源。

【解决方案6】：

我发现 clisp 中的错误消息更友好，可以帮助我更快地找到问题。

【讨论】：

【解决方案7】：

看来SBCL的REPL和clisp比较不友好？例如。我可以使用 TAB 键在 clisp 中自动完成输入。

所以 clisp 更适合 lisp 新手。

【讨论】：

SBCL 的 REPL 是极简主义的。一般来说，大多数 lisp 开发人员使用 SLIME，它提供了更好的 REPL。
但是我习惯用 vim 而不是 emacs
或在从命令行启动任何 lisp 时使用 rlwrap 实用程序。它使 REPL 更加友好。

【解决方案8】：

如果您在 Windows 下使用 cygwin 安装 clisp，我非常幸运。

【讨论】：

【解决方案9】：

取决于您选择的操作系统

Windows - 使用 ecl 或 abcl
Linux - 使用 sbcl 或 ecl 或 abcl 或 cmucl
Mac - ccl 或 ecl 或 sbcl
其他 - abcl 或 ecl 或 sbcl

编辑：

windows 上的 Sbcl 缺少线程，并且通常不是那么稳定，并且没有一个核心维护者使用 windows。

ecl 是跨平台 lisps 的更好选择，它的功能集在所有主要平台上同样稳定。

编辑 2011-10： Sbcl windows 现在支持线程。它还没有完全合并到 mainiline 中，但是有一个非常稳定的分支，它具有线程和其他 Windows 特定的好东西。

【讨论】：

我一直听说 sbcl 在 Windows 上不好，但我很少听到为什么。是什么让您在 Windows 上不使用 sbcl？是马车吗？
你忘了提到clozurecl。它是 openmcl 的演变。它很快（在编译速度和运行时速度方面），生成本机代码（但据我所知，比 sbcl 慢一些）。它适用于 x86 和 x86-64 的 windows 和 linux（也适用于其他操作系统）。 SBCL 在 Windows 上不稳定。它的线程支持尚未完全完成。
我提到它是ccl。这是很好的实施，但没有 SSE2 就无法工作，所以我无法运行它。
@MarkoKocić 你确定你的处理器缺少 SSE2 吗？仔细检查一下，自 Pentium III 以来的所有处理器都有它。附言还是拖钓？ :))
很难过。但是，要求 SSE2 使 CCL 开发人员能够有效地处理字符串，因为所有 CCL 字符串都是 32 位的。