4 ms·
A lot of parts of Clojure seemed to be created specifically with the JVM in mind. Not sure if porting it is a good idea.
by andreyf 18y ago
A lot of parts of Clojure seemed to be created specifically with the JVM in mind. Not sure if porting it is a good idea.
- chancho 18y agoCan you give some examples? (Not doubting. I don't know much about Clojure and I'm curious.)
- andreyf 18y agoMy only experience with Clojure is reveiwing Stuart Halloway's books on it, so this is certainly not the most qualified opinion you'll get, but as others have mentioned, tail-call optimization (lack thereof in the JVM, that is) significantly affected the language. It's not possible on the JVM, so Clojure relies heavily on the 'recur' keyword, so that recursive code can be translated into non-recursive bytecode. Another language feature that could be ignored is the trampoline, which is made easy with the #(foo 'bar %1) notation, but can be ignored if you're not worrying about the JVM. Aside from that, I would be very interested in seeing a Parrot Scheme based on ideas from Arc and Clojure both.
- celoyd 18y agoYep. Clojure is designed around the JVM and libraries written in Java-the-language. If you ported it, by the time you took out the Java-y stuff and added things like TCO and call/cc, it would be a new lisp. And I think new mid-sized lisps are what we need. If Parrot brings a wave of lisps bigger than Scheme but smaller than CL, designed for Unix and the internet, competing with Clojure and Arc, everyone wins. If they can call each other's libraries, it'll be wonderful. We should be looking way beyond Clojure.
- icey 18y agoAre you sure it is designed specifically around the JVM? Rich used to maintain side-by-side versions that ran on .Net and the JVM.
- celoyd 18y agoTail call optimization is an example of something that Clojure doesn't have because the JVM makes it hard, although it's easy (I'm told) on the .NET system.