> With the clojureclr for example, it > supports pretty much everything clojure does sans java, and gains all the > .net interop. >
True...true, it supports it, but it's still a "2nd class citizen". For instance, we don't have lein, ring, parts of contrib, IDEs, etc. All the examples, all the books are all about Clojure on the JVM. Do anything else and you can forget using Clojars, and 90% of the ecosystem built around Clojure. The other issue here, is that translating Clojure to CLR is a fairly straight forward task. C# and Java support most of the same language features. No so in Python. For instance, Python does not have anonymous classes, anonymous multi line lambdas (e.g. #(do (expr1) (expr2)) ), or overloaded constructors. So now, the entire structure of the code has to change. Now, what should be done at some point (IMO) is to implement Clojure in Clojure. This is why PyPy is so successful. They have written a Python interpreter in Python and then written a translator that can take a Python program and write a JIT for it. That JIT generator can then output many different code types. For instance, backends for C, LLVM, .NET and JVM all exist for PyPy...IMO this is what Clojure would need to be completely portable. ClojureScript comes close, all of ClojureScript is written in Clojure. However the actual code generation of ClojureScript is complected into the compiler. So there's a function in the compiler called "emit-call" but that function assumes you will always use it to emit js code. If we were able to abstract this compiler a bit more, we could write backends for Java/.NET/JS/PyPy/PHP(yuck) or whatever. Finally Clojure does make a few assumptions about the underlying VM. Clojure assumes that the entire system will run on a VM that only supports OOP. Hence every single function is a object. Now look at PyPy or JS, here functions are true values in the VM. So the best way to implement Clojure in PyPy would be to take advantage of these facilities. But then you're really re-defining what clojure is and how it runs. PyPy has a very advanced JIT that works well with dynamic typing, but if you implement stock Clojure on PyPy you'd be ignoring all that. Look at RT.java, you'll see tons of "if (obj is ISeq)... if (obj is Array)...". Much of that could be thrown away in a PyPy implementation, but if you threw that away, now you have a headache when the Clojure devs start updating the code, and you have to port those changes to your code base. Sorry for the rambling... 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
