最近，我开始学习cuis-smalltalk，但是我不知道使用Smalltalk的OOP与CLOS相比有多么深刻和深刻（我正在使用Ruby）。我了解到Smalltalk是一个本身实现的反射系统的好主意。我发现Ruby具有Rubinius，但是当我寻找用Lisp编写的Common Lisp实现时，找不到任何类似的东西。似乎没有用CL编写的CL发行版。
在具有CLOS和粘液的Common Lisp中，您可以完成Smalltalk开发环境中可以做的所有事情。
但是我有一个问题，一个Common Lisp实现本身是否对Common Lisp有用？或者不会为语言添加任何特殊内容，因为谐音，宏和MOP可以处理所有这些。为什么无法做到有技术上的限制？
答案 0 :(得分：13)
示例：SBCL
runtime的大部分仅在C中实现。
示例：Clozure Common Lisp
kernel用汇编器和C编写。
示例：Mezzano
Mezzano是完全用自己的Common Lisp编写的操作系统。它在金属上运行->意味着可以将其作为操作系统启动。
Smalltalks完全不是用Smalltalk编写的，Rubinius也不是完全用Ruby编写的
这与Squeak或Pharo之类的Smalltalk实现没有什么不同，Squeak或Pharo的大多数部分是用Smalltalk编写的，虚拟机的某些部分是从Smalltalk生成到C的，而虚拟机的某些部分是用C编写的。 >
Parts of Rubinius用C ++编写。
答案 1 :(得分：4)
您的假设是错误的，SICL是用常见的Lisp语言编写的常见的Lisp实现：https://github.com/robert-strandh/SICL
答案 2 :(得分：1)
我认为您正在混淆Common Lisp和CLOS。 CLOS（通常使用MOP来实现，但不是必需的）是Common Lisp提供的功能，但不要求Common Lisp本身的编写方式应尽可能使它实际使用CLOS。正如Rainer所言，Smalltalk VM并不是纯粹用Smalltalk编写的，并且Common Lisp（通常）已经很大程度上是用Common Lisp编写的（assembly / C / what有一些底层支持代码，还有一些本机库可用来提供Lisp运行时环境和Smalltalk VM一样，我怀疑Smalltalk VM会有更多的运行空间，这是因为VM提供了更高级别的抽象以及维护外观所需的更多支持/胶水代码。 / p>
我想您实际上要了解的是，如果用CLOS编写更多Lisp本身（如果那时不再使用Common Lisp）会很有用，因为通常实现的Common Lisp不会通常使用CLOS（完全使用？），而是将CLOS用作应用程序的可选OO框架。在（通常）实现的过程中，Smalltalk专注于发送到方法的消息（即在运行时做出决定），而Common Lisp则更专注于调用（非泛型）函数的宏（即在宏处执行很多但不是全部的决定）这些是基本的设计和实现决策，但是没有理由不能通过利用CLOS并将更多决策推迟到运行时来创建具有更Smalltalky感觉的Lisp。
正如您已经提到的，Lisp已经具有非常动态的环境，并且具有类似于Smalltalk的交互式“感觉”，那么这对您有什么帮助？通常，您将获得Smalltalk运行时所提供的更加极端的活力，从代码组织的角度来看，您将替换很多alist，plist，defparameter，defvar，并在一定程度上替换对象插槽使用的名称空间。您可能最终还会得到一小部分更通用的功能（Common Lisp提供了一种厨房水槽功能方法：几乎可以想象到的每个用例的宏和功能），以支持OO可以提供的更极端的功能（即透明代理对象变得难以实现，覆盖诸如调试器之类的子系统变得容易等。）虽然Smalltalk和Lisp之间的OO实现仍然存在差异（单派与多重派发，单派与多重继承，方法与通用功能，消息发送与函数调用等），我认为这可能为您带来Smalltalk提供的95％以上的收益。你要花多少钱？编译时清晰度和运行时性能... Smalltalk当前付出的代价。大多数Lispers可能最担心的是，代码在外观上会与以前不同，这与Clojure与Common Lisp的不同无异。因此，最终得到的是具有Smalltalky感觉的新Lisp，而不是另一个Common Lisp实现。