On Tue, Mar 5, 2013 at 1:33 AM, Christian Schafmeister <chris.schaf@verizon.net> wrote:
I needed a CL interpreter which would host the compiler (which I wrote in Common Lisp) which calls the LLVM-IR library to generate llvm::Module objects which contains llvm::Function objects that are Just-In-Time compiled into machine code and called via C function pointers from the Common Lisp or C++ code. 
I did not want to write a Common Lisp compiler in C++ (shudder).
This project started as an archaic Sexp walking Lisp interpreter that grew into a very slow Common Lisp Sexp walking interpreter within which I wrote a reasonably fast self-hosting Common Lisp compiler that generates LLVM-IR.

It would have been easier to rely on ECL's interpreter to do that. It is very small and the bytecodes interpreter already may run _all_ of Common Lisp at a reasonable speed.
 
I didn't know that when I started. I know that now - the bridge doesn't require the compiler and LLVM backend 
- the CL/C++ bridge is all C++ template programming, lots and lots of template programming. 
It's styled after the boost::python library if you are familiar with it.
Once I started writing the compiler and exposing and using the LLVM backend I just kept going.
Although, having intimate familiarity with the Common Lisp implementation I wrote has greatly facilitated the development of the bridge.

I did not know about Boost::Python. On reading it, it seems that, though horrible, it would be easy to port to any Common Lisp out there. If I were to write that, though, I would not do it as they do, with such undecipherable template code -- templates perhaps yes, but at least attempting something more readable.
 
We could get it to work with ECL as well if you want it - although it's going to take some work.

As I said, I believe this can be ported to _any_ Common Lisp. 
 
Then we could incorporate the LLVM-IR generating compiler into ECL.

I would love this, but I would love it even more if the LLVM-IR used the current compiler -- we do some pretty nifty optimizations and type inference there which any too straightforward LLVM implementation will miss.
 
1) C++ classes behave like CL structures.

They are opaque, then, not exposing any inheritance? Or do you allow class B which inherits from A to use the same functions as A? Do you expose methods from inherited classes with the same name, as in Python, or with different names, as in SWIG?
 
3) Memory management is currently handled using reference counted C++ shared_ptr/weak_ptr.  I plan to add mark-and-sweep GC later.

Even with shared_ptr there are problems. Note the examples of SWIG, where you have class class A { class B *b; } and then return field "b" of A to Common Lisp. How do you handle ownership there? Boost::Python is mind bloging and too ugly / fragile in this respect.

Best,

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com