On Mon, Feb 16, 2009 at 5:43 PM, dmiller <dmiller2...@gmail.com> wrote: > > The code will go up on clojure-contrib ASAP. I need input from the > clojure-contrib project members on how they operate, where they want > to put it, etc.
I don't know if you've looked at ClojureScript at all, but it's a similar if noticeably less ambitious project to compile Clojure code to JavaScript. It's in clojure-contrib already, but in trunk/clojurescript instead of trunk/src. My reasons for this were (1) I wasn't quite sure how to lay out the directory structure and didn't want to mess up anyone else, and (2) it doesn't work with Clojure trunk but instead requires a patch and rebuild of Clojure itself. This patch is stored right there in contrib as well. I think I've worked out (1) well enough, but (2) is still a factor. As it is, I never get complaints from people trying to use it with an unpatched Clojure and getting errors. Then again that may have more to do with the inscrutability and lack of docs. :-) Once Rich has applied the patch and ClojureScript can work with a regular build of Clojure (or at least as well there as anywhere), I plan to move the files into trunk/src/clojure/contrib/clojurescript I don't know if that same idea would be appropriate for your project, but it does make the code accessible without people using it accidentally. > The basic runtime data structures--the persistent collections, > namespaces/symbols/keywords, vars, refs, atoms, agents, etc.--are 95% > complete. The remaining pieces are trivial. Fantastic! For ClojureScript, at least, that has been the bulk of the work. > core.clj loads with minor edits (java.util.Collection => > System.Collections.ICollection, for example). Of roughly 425 def > forms in core.clj, only 43 are commented out. 19 of those are for > specialized array access, 6 for regular expressions -- nothing > significant in terms of work. This is the majority of what the ClojureScript patch changes -- moving explicit uses of non-Clojure Java class names out of .clj files and into clojure.lang.RT (or other appropriate Clojure classes) so that the .clj can be loaded as-is. RT and Numbers have to be ported by hand anyway, so it's not significantly worse on that end. I'd be very interested to compare notes and see if our needs have a common solution. > So there you have it. I'll post again when the code becomes available > on clojure-contrib. Sounds great! But there's one very important question you didn't address. What are you going to call it? :-) Seriously, though, since it seems likely that a majority of code written to run on your port will not work on Clojure/JVM, because of the runtime libs available (please correct me if I'm wrong), it's important for a body of code to be able to clearly declare where it's supposed to work. A name that is used consistently can help, I would think. --Chouser --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
