Still pondering whether to do this. The decompiler part is easy, it's the modifications to the Clojure Runtime that are the unknown.
I'm also putting a lot of faith in the GWT compiler to aggressively optimize the code - but, having watched this IO video, I think it is well placed.
Update: So, after examining the bytecode generated by the Clojure compiler, this is not looking like such a nice approach. A Clojure defn becomes a class unto itself, with static initializers and other overhead. It would be nice if a function was just a single method on a class representing the namespace it belongs to. That would allow GWT to translate it to a single Javascript function, which is how it should be.
Will be hacking on the Clojure compiler itself - to generate GWT-friendly Java source instead of bytecode.
Posts
4 comments:
Here's the beauty of LISPs. There's no need to hack the compiler. Create macros for clojure.core functions and macros which, instead of evaluating to expanding all the way to Clojure's primitives, emit Java source code or, better yet just directly emit JavaScript and avoid the GWT stack entirely.
There's also contrib.clojurescript:
http://github.com/richhickey/clojure-contrib/tree/master/clojurescript/src/clojure/contrib/clojurescript
Thanks Anonymous - I hadn't thought of replacing parts of the core Clojure API with macros. Will do some experimentation..
I did look a little at clojurescript- but, apart from not being an active project, it only targets a subset of Clojure. I'll dig deeper into that, too.
GWT does some aggressive whole-program optimization of the Java source and also the emitted JS, so I think it is still worth using. UiBinder is a really nice way to lay out UIs, too (a bit like Flex MXML).
Hi Nick,
This is a really great idea man! Have you gotten any luck on this idea? Would love to know the progress so far.
@jose - I've heard that the Clojure core team are working on improving their Clojure->JS tool, so I'm not spending much more time on this.
Post a Comment