为什么没有用公共Lisp编写的公共Lisp实现?

示例:SBCL

• Machine code compiler 口齿不清
• CLOS
• Interpreter 口齿不清
• Implementation

大部分只是 runtime

示例:Clozure Common Lisp

• Machine code compiler 口齿不清
• 在Lisp中实现: level 0 , level 1 , lib , library

kernel 是用汇编语言和C语言编写的。

Mezzano 是一个完全用自己的通用Lisp编写的操作系统。它在金属上运行->意味着可以作为操作系统引导到它。

Smalltalks既不是完全用Smalltalk编写的,Rubinius也不是完全用Ruby编写的

这与Squeak或Pharo之类的Smalltalk实现没有什么不同,在这些实现中,大多数部分是用Smalltalk编写的,虚拟机的某些部分是用Smalltalk生成的,而有些部分是用C编写的。

Parts of Rubinius

您的假设不正确,SICL是用common lisp编写的通用lisp实现: https://github.com/robert-strandh/SICL

我觉得你把普通的口齿不清和CLOS混为一谈了。CLOS(通常使用MOP实现,但不是必需的)是Common Lisp提供的一种工具,但并不要求Common Lisp本身的编写方式能够在可能的情况下实际使用CLOS。正如Rainer所提到的,Smalltalk VM并不是纯用Smalltalk编写的,Common Lisp(通常)已经基本上是用Common Lisp编写的(assembly/C/whatever中有一些低级的支持代码,以及一些本地库用来提供Lisp运行时环境,就像Smalltalk VM一样。我怀疑Smalltalk VM有更多这样的功能,因为VM提供了更高级别的抽象,并且需要更多的支持/粘合代码来维护facade。)

我认为您实际上得到的是,如果更多的Lisp本身是用CLOS编写的(在那一点上,这可能不再是普通的Lisp了),那么它是否会有用,因为通常实现的普通Lisp通常不使用CLOS(一点也不?),而是使CLOS作为应用程序的可选OO框架可用。由于Smalltalk是(通常)实现的,它关注的是发送给方法的消息(即在运行时做决定),而Common Lisp更关注的是宏调用(非泛型)函数(即做很多,但不是全部,编译时的决策。)这些是基本的设计和实现决策,但是没有理由不能通过使用clo和将更多的决策推迟到运行时来创建一个更简洁的Lisp。

正如您已经注意到的,Lisp已经有了一个非常动态的环境,具有类似于Smalltalk的交互“感觉”,那么这会给您带来什么呢?通常,您会得到Smalltalk运行时提供的更为极端的动态性,从代码组织的角度来看,您将替换很多alist、plist、defpareter、defvar,并在某种程度上替换对象槽中使用的名称空间。您可能还会得到一组更小的更通用的功能(Common Lisp提供了一种厨房水槽的功能方法:宏和函数,几乎适用于您可以想象的每一个用例),以支持OO可以提供的更极端的功能(即透明的代理对象实现起来很简单,覆盖子系统)就像调试器变得简单等)虽然Smalltalk和Lisp在面向对象实现上仍然存在差异(单分派与多分派、单继承与多继承、方法与泛型函数、消息发送与函数调用等),但我认为这可能使您获得Smalltalk提供的95%以上的功能。你花了多少钱?编译时清晰度和运行时性能。。。Smalltalk目前支付的价格。大多数Lisper可能更关心的是,代码的外观和感觉与他们所习惯的不同,而不像Clojure与普通Lisp的不同。因此,您最终得到的是一个新的Lisp,它有一种简单的感觉,而不是另一个常见的Lisp实现。