On Tue, May 15, 2012 at 8:05 AM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > There seems to be a few steps involved in this from, what I'm seeing. > > From what I'm seeing of the source, there's two files I'll be dealing with > > closure.clj -- defines functions for looking up info about libraries, > functions, etc. > compiler.clj -- actually defines the compiler > > To start with, I'm thinking of trying to compile ClojureScript in > ClojureScript. I know this won't work if the user has optimized > ClojureScript at all, but it should be a good testing point. > > The first step in this process would then be to write a version of > closure.clj in ClojureScript. Somehow it would present the same > interface as closure.clj but in a JS environment. I'll have to look > into how well that may work out. I'm going to call this file the > platform.clj file. > > From there I'll need to take a look at the GSOC work (where is that > currently?) to see how much of the compiler I'd need to modify. But > we'd basically need to re-write the compiler to use only ClojureScript > compatible forms. From there it should be fairly complete. > > So the way I'd then port ClojureScript to Python would be the following: > > 1) Write a platform.clj (closure.clj) file for Python. This would > somehow allow Java to tap into Python and run reflection on the > modules in Python. > 2) Implement a Python back-end for the GSOC pluggable-backend > 3) Compile compiler.clj into one massive python file > 4) Write a new platform.clj file to just look at the Python VM instead > of going from Java->Python->Modules > 5) Compile compiler.clj into one massive python file > 6) ... > 7) Profit! > > Long term I'm only seeing that we'll need to write 3 files each time > we want to port ClojureScript to a new platform: > > 1) The Java version of platform.clj > 2) The compiler backend > 3) A "native" version of platform.clj > > I'm going to look into the GSOC stuff next to make sure I'm not going > to duplicate anyone's work. > > Timothy
Logically the interface between the analyzer and the emitter is data (maps, etc) which can be serialized as json or some platform specific representation. Then all you need to do is write an emitter on your platform of choice that can emit code for the data. So for Python: 1. run the analyzer on itself to get the data describing it 2. serialize that data in some format Python can read 3. write an emitter in Python 4. feed the analyzer data to the emitter 5. hook the emitted analyzer code up to the emitter so the whole thing pivots around the data emitted from the analyzer > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
