[Ecls-list] Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

[Juan Jose Garcia-Ripoll]

On Tue, Mar 5, 2013 at 1:33 AM, Christian Schafmeister <
chris.schaf at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130305/e5423d7a/attachment.html>