Sounds reasonable. Is there some specific direction you are suggesting? David
On Mon, May 14, 2012 at 8:35 AM, Timothy Baldridge <tbaldri...@gmail.com>wrote: > Over the weekend there was some talk in IRC about why clojure-py > didn't use Clojurescript as the basis for its compiler. The reasons I > had, basically boiled down to this: Clojurescript is written in > Clojure-JVM and as such requires that the JVM be installed, and also > requires that all macros be Clojure-JVM and not ClojureScript. For > Clojurescript this is fine. But for Clojure-Py this results in me > writing a fair amount of "translated" code. Recently I've been > thinking about how to change this. > > Much of the more recent code in Clojure is very cross platform. Stuff > like reducers can simply be copied over, fixed up a bit, and it runs. > If we could ever get to the point where we write Clojure in Clojure, > by default, then we could support the CLR, PVM, gambit, js, lua, etc. > all with a single file edit. > > Over the weekend I've been thinking over how to make this all > possible, and I think we're very close. The GSOC projects are working > at making a plugable backend (code emmiters) for ClojureScript, so > that part is being taken care of. All we really need now, is a > cross-platform ClojureScript compiler in ClojureScript. From there, > porting to a new platform would be simple: > > 1) generate a new backed as per the GSOC project > 2) compile the ClojureScript compiler using the new backend > 3) compile your code using "native" macros, etc. > > Platforms that do not have the ability to eval (gambit, JS, etc.) they > could simply stick with writing Java macros. For the rest of the > platforms (CLR, JVM, PVM, lua) they could then have native macros and > be able to distribute only non-Java code. > > One of the original goals of Clojure-py was to be able to translate > the entire compiler and runtime to RPython. However, to make this > happen, certain things must be changed in the Python code. For > instance, all primitives must be boxed. This means turning code like > this: > > x = 1 + 2 > > into this: > > x = W_Add(Int(1), Int(2)) > > Under the current Clojure-py codebase this would be a bit hard to > maintain. However, with Clojure-in-Clojure this is just a different > backend. > > I see this all as being a major boon to anyone looking to port Clojure > to a different platform. Hopefully at this point we could start > looking at what it would take to port Clojure to LLVM and CUDA. > > Thoughts from the ClojureScript, clojure-gambit, GSOC people? > > Timothy Baldridge (halagri) > > -- > 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 -- 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
