I actually started on this at one point. I ended up scrapping the project for several reasons. But first, I think we must clarify what we mean by "runs on pypy". There's two ways of attacking such a project:
1) writing a Clojure interpreter in RPython, and then having PyPy generate a JIT for you. This would, by far, create the fastest solution. PyPy loves creating JITs for languages with immutable data and pure functions. In fact, the JIT goes bonkers with optimization when it comes to programs that follow this criteria. So going this route would allow you to tell the JIT generator that all your functions are pure, and all your data is immutable. The bad thing is, you have no library...you have to write your entire runtime library yourself. 2) writing a Clojure -> Python translator, then run the resulting code in PyPy (like Clojurescript does with JS). Here the JIT will be a bit more "unhappy" since you could change the classes at any moment. Now the fact that you don't change it means that the performance impact will be lessened somewhat, but still the impact will be there. Now both solutions will take two things from you 1) the extensive library of the JVM. The more I work with the JVM (I'm a .NET guy), the more I see the value of the platform. 2) you loose co-currency. Most PyPy code is not thread safe, so there's that. But I have to disagree with Bret on his comments about how advanced the JVM is. True the Sun JVM is advanced, but you have to understand how truely complex the JVM bytecode is. On top of this, no JVM I know actually implements a tracing JIT. This is where PyPy excels. PyPy profiles the code while it is running and does some truely insane optimizations. For instance, PyPy will rip apart data structs. So if Foo.x is the only member used from the Foo struct in function Bar, PyPy will re-write a version of Bar on-the-fly so that Bar takes a single int instead of a full struct. PyPy then also removes unneeded allocations, etc. Basically it unboxes primitives and generates code using those primitives while the program is running. On top of all that, the tracing JIT of PyPy will string functions together, finding the loops in the actual code, then JIT native code to represent these loops. The net effect of this is, that many functions (regex engines, string functions, and yes even video processing) run just as fast in PyPy as in pure C code. And in some cases, PyPy can generate code faster than hand-written C code. So all that to say, yes, I think there's a lot of potential in PyPy, but translating Clojure to it is no small task. And even when you're done, you're still in the same boat as Clojure-CLR and ClojureScript...no matter how good you are, you're still not "real" Clojure. Timothy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
