> No particular plans. Why would you prefer that? Simplicity for one thing, self hosting for another. This is the problem I see with a project like this:
1) My macros are written in Clojure for the JVM, my code is written in Clojure for C 2) My code path is then ClojureScript->JVM Macros->C->GCC. So I'm basically touching what...5 platforms/languages? (JVM, Clojure, ClojureScript, C) 3) What if I have a syntax error in C? Now I have to understand how to deal with syntax/runtime errors in 3 languages (JVM for macros, Clojure for runtime errors, and C for compile errors). With LLVM you can get rid of the C and GCC steps. And, if you use LLVM bindings for Java, you can skip the source code output part of all this. At that point your tool chain would consist mostly of JVM, and Clojure and a few binary blobs. You can basically treat LLVM as an AST. As an example see this: http://code.google.com/p/pymothoa/ So the idea is, compile your stdlib to .o files, then have LLVM load them. At this point it's a simple tree transform from Clojure's data structures to LLVM, and from there to a binary output. There are no C syntax errors, since there is no C code being compiled. Since errors could be caught in the ClojureScript compiler, you could output meaningful information like (error in line 33 of core.clj) instead of worthless messages like (syntax error at line 13233 in FF3RXG.c). Never been much of a fan of source-to-source translators to be honest. 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
