Interoperability between clojure and python is promising, because it lets you do lisp programming with python libraries and data structures.
If you want to do lisp programming with CL libraries, you could just use CL.
I'm not sure what the advantage of clojure in CL is over just using CL.
I dougth CL-Clojure is faster then pypy-Clojure.
Why? CL compilers (SBCL at least) generate really fast code.
It does not matter with how good a compiler you compile an interpreter it stays an interpreter. With Pypy you get a JIT Compiler. Sure you could maybe write a JIT with CL but thats a lot more work.
I don't understand. Do you mean that you can't compile Clojure into Common Lisp the way you can compile it into Python/PyPy?
You can, but I think you'd run into the same issues mentioned here: http://clojure-py.blogspot.com/2012/02/ive-been-asked-many-t...
Basically it reflection (aka dynamic dispatch) is a major performance killer if you don't implement a tracing jit.
CLOS implementations have had to deal with the problem of extreme dynamism for a long time, so there has been quite a bit of optimization work associated with it. Polymorphic inline caches help a lot, for example.
That said, a good tracing JIT is probably better; but on the other hand, SBCL has profited from many years of optimization work on CMU CL. It would be interesting to see some real-world performance comparisons between SBCL and PyPy.
Re:Clojure Implemented in Pure Python
by pavelludiq on Thursday March 01, 2012 @11:25AM
(#3652739)
Wouldn't SBCLs type inference(+ type hints) help with this? I'm no compiler expert, but i think clojure(with the possible exception of multimethods, which are slow even on the JVM) would map well to CL(maybe even better than the JVM).
PyPy is not just an Python-Interpreter. The PyPy Team build a Toolchain that can creat a JIT-Compiler out of a Interpreter (read some about the pypy project and you will be enlightened. Such a Toolchain does not exist for Common Lisp.
In general I think Common Lisp's virtues as an implementation substrate for other languages are much greater than most people appreciate. It is flexible, expressive, and fast. Its dynamicity comes in very handy. And some of its vices -- its sheer size, its lack of orthogonality, and its occasionally archaic naming conventions -- are much less problematic for a language implementation task than they are for general programming.
There are exceptions, of course. You wouldn't want to implement C++ in Common Lisp. But for dynamically typed languages it ought to be a leading candidate.