On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <chris.schaf@verizon.net> wrote:
I've created a new implementation of Common Lisp that has a core written in C++ completely from scratch but hosts the ECL Common Lisp source code.

Sounds like a lot of work.
It hosts all of the ECL Common Lisp code in the ecl/src/lsp and ecl/src/clos directories of the ECL source tree.
I do not use any part of the ECL CL->C compiler or the byte code compiler.
I've implemented my own CL interpreter and CL->LLVM-IR->native code compiler.

I do not understand why you reimplemented the interpreter, but the LLVM thingy looks interesting.
It's purpose is to make possible the seamless interfacing of C++ libraries with Common Lisp code and vice versa.
Within this new implementation it is trivial to interface complex C++ libraries containing classes, virtual functions, overloaded functions etc with Common Lisp code.

Sorry, but I do not understand this. There are different things in interfacing Common-Lisp with C++, and none of them requires building a new compiler or a LLVM backend.
Why - you ask?  I'd be happy to explain over a beer or coffee sometime.
In a nutshell - I want this for my research and prior to my writing it there was no Common Lisp implementation that interfaces seamlessly with C++.
ECL does a great job with "C" but "C++" is a much more complex language to interface with and I have a lot of C++ code that I need to interface with.

If you state that ECL cannot interface with C++ I would like to see that statement backed with examples. EQL is one example that interfacing is not impossible and, probably, not that hard once you can write C++ inside Common Lisp code.

But most important, the issue of interfacing Common Lisp and C++ consists on many different problems that I do not see how you solve at the same time with the help of LLVM

1. Integrating the C++ type system and the Common Lisp one
2. Being able to call C++ functions from Common Lisp and viceversa
3. Integrating C++ and Common Lisp memory management
4. Possibly automating the generation of wrappers for C++ code.
5. Resolving overloading at runtime instead of at compilation time.

Many issues, some of which are mentioned in SWIG, http://www.swig.org/Doc1.3/SWIGPlus.html but even many of which they (working long in the interface between C++ and dynamic languages) do not have an answer to.


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