I've just managed to host much of the ECL Common Lisp code on a C++ core that was built completely from scratch.
I just got ECL-CLOS and generic function dispatching to compile and run a few days ago.
I've exposed the LLVM C++ library to Common Lisp and written a new self-hosting compiler in CL.
I also wrote an S-expression walking CL interpreter to bootstrap the compiler.

It's taken me about a year working about 8 hours a day.  It's my first time and I have no previous experience with Common Lisp.

Juanjo is absolutely correct, it's the interactions of the CL code with the lower level code that require a lot of time to implement properly. 
This involves a lot of implementation dependent stuff that are not described in the CL standard.

When I started seriously trying to host the ECL code I had Juanjo's excellent ECL C-code to help me understand what the low-level functionality did. 

Also, very important details like lexical environments are not described at all well in the CL standard and you need to do a lot of code refactoring to get something that works properly in the end.

Also, tracking down subtle bugs that I introduced because I didn't exactly implement standard Common Lisp behavior the first, second or third time around has taken a lot of my time.



On Apr 18, 2013, at 9:10 AM, Juan Jose Garcia-Ripoll <> wrote:

On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <> wrote:
In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.
How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.

Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)