<div dir="ltr">On Tue, Mar 5, 2013 at 1:33 AM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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. <br>
<div>I did not want to write a Common Lisp compiler in C++ (shudder).</div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>I didn't know that when I started. I know that now - the bridge doesn't require the compiler and LLVM backend </div>
<div>- the CL/C++ bridge is all C++ template programming, lots and lots of template programming. </div><div>It's styled after the boost::python library if you are familiar with it.</div><div>Once I started writing the compiler and exposing and using the LLVM backend I just kept going.</div>
<div>Although, having intimate familiarity with the Common Lisp implementation I wrote has greatly facilitated the development of the bridge.</div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><span style="color:rgb(34,34,34)">We could get it to work with ECL as well if you want it - although it's going to take some work.</span></div>
</div></div></div></blockquote><div><br></div><div>As I said, I believe this can be ported to _any_ Common Lisp. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div><span style="color:rgb(34,34,34)">Then we could incorporate the LLVM-IR generating compiler into ECL.</span></div></div></div></div></blockquote><div><br></div><div>
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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>1) C++ classes behave like CL structures.</div></div></blockquote><div>
<br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>3) Memory management is currently handled using reference counted C++ shared_ptr/weak_ptr. I plan to add mark-and-sweep GC later.</div>
</div></blockquote></div><div><br></div><div style>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.</div>
<div style><br></div><div style>Best,</div><div style><br></div><div style>Juanjo</div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a>
</div></div>