为什么没有用Common Lisp编写的Common Lisp实现？

Question

最近，我开始学习cuis-smalltalk，并意识到与CLOS（我正在使用Ruby）相比，Smalltalk的面向对象编程思想是多么深奥和深刻。我了解到Smalltalk是一个自我实现的反射系统的伟大思想。我发现Ruby有Rubinius，但当我寻找用Lisp编写的Common Lisp实现时，我找不到类似的东西。似乎没有用CL编写的CL分发。

在具有CLOS和slime的Common Lisp中，您可以做所有可以在Smalltalk开发环境中完成的事情。

但我有一个问题，即自己的Common Lisp实现是否对Common Lisp有用？还是因为同构性、宏和MOP可以处理所有内容，所以不会添加任何特殊的语言功能。是否存在技术限制，无法实现这一点？

- anquegi

---

许多通用Lisp实现大部分都是用Lisp本身编写的：SBCL、CCL、Allegro CL、LispWorks、CMUCL等等。运行时的某些部分可以用汇编、C或类似语言编写。这与Smalltalk没有什么不同，因为Smalltalk VM的某些部分通常也是用C编写的——除了那些将Smalltalk子集编译为C的VM部分之外。通常，Lisp实现不使用VM，而是使用用Lisp编写的编译器生成机器代码或C代码（或JVM代码等）。 - Rainer Joswig

看起来 Rubinius 的 GC 不是用 Ruby 写的，而是用 C++ 写的：https://github.com/rubinius/rubinius/blob/master/machine/memory/gc.cpp - Rainer Joswig

@RainerJoswig：没有任何一个虚拟机是用Ruby编写的。Rubinius是一种典型的动态语言实现，具有将Ruby编译为字节码和字节码虚拟机的编译器。与前者相关的所有内容都是用Ruby编写的（编译器、标准库、核心库、内核），但与后者相关的所有内容都是用C++编写的（VM、解释器、GC、对象内存、一些基本的核心类和方法）。就像大多数Smalltalk一样。此外，正则表达式引擎与YARV相同（Onigmo），它本身的C代码量已经超过了VM的C++和编译器和lib组合的Ruby的代码量。 - Jörg W Mittag

这个已经废弃的JIT编译器也是用C++编写的，实际上使用了LLVM API。我认为新的JIT应该是用Ruby编写的，以便更容易进行实验、可维护性和可读性更高。 - Jörg W Mittag

@anquegi：你可能会对Klein感到高兴，它是一个用Self语言编写的VM，实际上在自身内部运行。我不是指在另一个实例之上运行一个Klein实例。它确实在自身内部运行，并使用自身重新编译自身。这是令人费解的。最初的Self开发人员之一创建了Maxine，这是基于相同概念的JVM。一些来自Maxine的想法现在正在流入Oracle JDK。 - Jörg W Mittag

Answer 1

示例：SBCL

• Lisp中的机器码编译器
• Lisp中的CLOS
• Lisp中的解释器
• 在Lisp中的实现

大部分仅有运行时的大部分实现是用C编写的。

示例：Clozure Common Lisp

• Lisp中的机器码编译器
• Lisp中的实现：level 0、level 1、lib、library

内核是用汇编和C编写的。

例子：Mezzano

Mezzano 是一个完全用自己的 Common Lisp 语言编写的操作系统。它可以在硬件上运行 - 这意味着可以将其作为操作系统启动。

既不是 Smalltalk 的所有实现都完全使用 Smalltalk 编写，也不是 Rubinius 完全使用 Ruby 编写

这与 Smalltalk 实现（如 Squeak 或 Pharo）没有什么不同，其中大部分部分都是用 Smalltalk 编写的，虚拟机的一些部分是从 Smalltalk 生成到 C 中，而虚拟机的一些部分则是用 C 编写的。

Rubinius 的某些部分是用 C++ 编写的。

- Rainer Joswig

---

Bee Smalltalk 完全使用 Smalltalk 编写。 - Leandro Caniglia

Vast VM（VA Smalltalk）也是一种老的VM，它使用了Smalltalk模型代码和可移植汇编语言（用于跨平台）。更多信息请参见：http://www.instantiations.com/PDFs/presentations/Smalltalks2015/VA%20Smalltalk%20VM-Smalltalks2015.pdf - tukan

Answer 2

你的假设是不正确的，SICL是一个用common lisp编写的common lisp实现：https://github.com/robert-strandh/SICL。

- jmercouris

---

SICL 确实很酷，但可能不应该算作完整的 Lisp 实现。但就 Lisp 中的 Lisp 而言，SICL 中的 CLOS 引导是值得一看的。 - Dan Robertson

Answer 3

我认为你混淆了Common Lisp和CLOS。CLOS（通常使用MOP实现，但不是必需的）是由Common Lisp提供的一种工具，但并不要求Common Lisp本身在可能的情况下实际使用CLOS。正如Rainer所提到的，Smalltalk VM并非纯粹用Smalltalk编写，而Common Lisp（通常）已经大部分用Common Lisp编写（有一些低级支持代码以汇编/C/任何其他语言编写，以及一些本地库用于提供Lisp运行时环境，就像为Smalltalk VM提供的那样。我会怀疑由于VM提供更高级别的抽象，需要更多的支持/粘合代码来维护外观）。

我认为你实际上想知道的是，如果更多的Lisp本身是用CLOS编写的话是否有用（此时可能不再是Common Lisp），因为通常实现的Common Lisp并不一般使用CLOS，而是将CLOS作为可选的OO框架提供给应用程序。按照（通常）的实现方式，Smalltalk侧重于向方法发送消息（即在运行时做出决策），而Common Lisp更侧重于宏调用（非泛型）函数（即在编译时做出许多决策，但不是所有决策）。这些是基本的设计和实现决策，但没有理由不能创建一个Lisp，它具有更Smalltalky的“感觉”，通过利用CLOS并将更多的决策推迟到运行时。

正如你已经注意到的，Lisp已经具有非常动态的环境，并具有类似于Smalltalk的交互式“感觉”，那么这会给你带来什么？通常，您会获得Smalltalk运行时提供的更极端的动态性，并且从代码组织的角度来看，您将使用对象槽替换大量用于alist、plist、defparameter、defvar以及在一定程度上用于命名空间的内容。您可能还会得到一组更通用的功能（Common Lisp为几乎可以想象的每个用例提供宏和函数），以支持OO可以提供的更极端的功能（例如，透明代理对象变得容易实现，覆盖子系统如调试器变得容易等）。虽然Smalltalk和Lisp之间的OO实现仍存在差异（单分派vs多分派，单继承vs多继承，方法vs泛型函数，消息发送vs函数调用等），但我认为这可能可以为您提供95%以上的Smalltalk提供的内容。它的成本是什么？编译时清晰度和运行时性能...目前Smalltalk正在支付的代价。对大多数Lisper来说，更大的问题可能是代码看起来和感觉与他们习惯的不同，就像Clojure与Common Lisp不同一样。因此，你最终会得到一个具有Smalltalky感觉的新Lisp，而不是另一个Common Lisp实现。

- blihp