Why isn't there a Common Lisp implementation written in Common Lisp?

7
votes

Recently, I started to learn cuis-smalltalk, and no I realize how profound and deep OOP with Smalltalk is compared to CLOS (I'm using Ruby). I learned the great idea of that Smalltalk is a reflective system implemented in itself. I found that Ruby has Rubinius, but when I looked for a Common Lisp implementation written in Lisp, I could not find anything similar. There doesn't seem to be a CL distribution written in CL.

In Common Lisp with the CLOS and slime, you can do all the things that can do with the Smalltalk Development environment.

But I have the question if a Common Lisp implementation of itself could be useful for Common Lisp? Or will not add anything special to language because homoiconicity, macros and MOP can handle it all. Are there technical limitations of why it could not be done?

3
common-lispsmalltalk
Your question is not clear, at least to me (I'm not the downvoter though.) – Leandro Caniglia
Many Common Lisp implementations are written mostly in itself: SBCL, CCL, Allegro CL, LispWorks, CMUCL, etc. etc. Parts of the runtime can be written in assembler, C, or similar. This is no different from Smalltalk, since parts of the Smalltalk VM are usually also written in C - in addition to the parts of the VM where a Smalltalk subset compiles to C. Often Lisp implementations don't use VMs and use compilers written in Lisp to generate machine code or C code (or JVM code, ...). – Rainer Joswig
@RainerJoswig: None of the VM is written in Ruby. Rubinius is a typical dynamic language implementation with a compiler that compiles Ruby to bytecode and a bytecode VM. Anything related to the former is written in Ruby (compiler, standard library, core library, kernel), but anything related to the latter is written in C++ (VM, interpreter, GC, object memory, some basic core classes and methods). Just like most Smalltalks. Also, the Regexp engine is the same as in YARV (Onigmo), which by itself is already more C code than the C++ of the VM and the Ruby of the compiler and lib combined. – Jörg W Mittag
The now-defunct JIT compiler was also written in C++, actually using the LLVM API. I think the new JIT is supposed to be written in Ruby for easier experimentation, maintainability and readability. – Jörg W Mittag
@anquegi: You might be delighted by Klein, a VM for Self that is not only written in Self, but actually runs inside itself. And I don't mean running one instance of Klein on top of another instance. It actually does run in itself, recompiling itself with itself. It's mindbending. One of the original Self developers started Maxine, a JVM based on the same concepts. Some ideas from Maxine are now trickling back into Oracle JDK. – Jörg W Mittag

3 Answers

13
votes

Example: SBCL

Mostly only large parts of the runtime are implemented in C.

Example: Clozure Common Lisp

The kernel is written in assembler and C.

Example: Mezzano

Mezzano is an OS fully written in its own Common Lisp. It runs on the metal -> means one can boot into it as an operating system.

Neither Smalltalks are completely written in Smalltalk, nor is Rubinius completely written in Ruby

This is no different from Smalltalk implementations like Squeak or Pharo, where most parts are written in Smalltalk, some parts of the Virtual Machine are generated from Smalltalk to C, and some parts of the Virtual Machine are written in C.

Parts of Rubinius are written in C++.

4
votes

Your assumption is incorrect, SICL is a common lisp implementation written in common lisp: https://github.com/robert-strandh/SICL

1
votes

I think you're conflating Common Lisp and CLOS. CLOS (usually implemented using the MOP but not required) is a facility provided by Common Lisp, but there's no requirement that Common Lisp itself be written in such a way that it actually use CLOS where possible. As Rainer mentioned, the Smalltalk VM isn't purely written in Smalltalk and Common Lisp is (often) already largely written in Common Lisp (there is some low-level support code in assembly/C/whatever and some native libraries utilized to provide the Lisp runtime environment just as there is for the Smalltalk VM. I would suspect that there is more of it for the Smalltalk VM due to the higher-level abstraction that the VM provides and more support/glue code needed to maintain the facade.)

What I think you're actually getting at is if it would be useful if more of Lisp itself were written in CLOS (which at that point would probably not be Common Lisp anymore) since Common Lisp as it is usually implemented does not generally use CLOS (at all?), but rather makes CLOS available as an optional OO framework for your applications. As it is (commonly) implemented, Smalltalk is focused on messages being sent to methods (i.e. making decisions at runtime) and Common Lisp is more focused on macros calling (non-generic) functions (i.e. making many, but not all, decisions at compile-time.) These are fundamental design and implementation decisions but there's no reason you couldn't create a Lisp that had a more Smalltalky 'feel' by utilizing CLOS and deferring more decisions to runtime.

As you've already noted, Lisp already has a very dynamic environment with a similar interactive 'feel' to Smalltalk, so what would this get you? Generally, you'd get the more extreme dynamism that the Smalltalk runtime offers and from a code organization standpoint you would replace a lot of what alist, plist, defparameter, defvar, and to an extent what namespaces are used for with object slots. You would probably also end up with a smaller set of more general functionality (Common Lisp offers a kitchen sink approach to functionality: macros and functions for nearly every use case you can imagine) to support the more extreme capabilities that OO can offer (i.e. transparent proxy objects become trivial to implement, overriding subsystems like the debugger becomes easy etc.) While there are still differences in OO implementations between Smalltalk and Lisp (single vs. multiple-dispatch, single vs. multiple-inheritance, methods vs. generic functions, message sends vs. function calls etc.), I think this could probably get you 95%+ of what Smalltalk offers. What does it cost you? Compile-time clarity and runtime performance... a price Smalltalk pays currently. Probably of greater concern to most Lispers would be that code would look and feel different from what they're used to not unlike how Clojure is different from Common Lisp. So what you'd end up with is a new Lisp with a Smalltalky feel rather than another Common Lisp implementation.