2014-05-19 3:27 GMT+02:00 Wes Brown <[email protected]>: > > My scope is a lot less ambitious than this -- so for context, this is the > current state of cljs-in-cljs as I see it:
> * Joel Martin (kanaka) and Chris Houser's (chouser) work on cljs-in-cljs > did quite a few steps towards ClojureScript being able to compile itself; > you could even have a REPL that evaluates and compiles ClojureScript, and > defmacro works. This works well enough that I've been able to build a > non-trivial application on top of cljs-in-cljs. > Link: https://github.com/kanaka/clojurescript > * However, this fork of Clojurescript originated in 2012. There is quite > a bit of bit rot due to this; it is nontrivial to get some ClojureScript > code to work due to the vintage o the code. It's been more than a year > since serious work has been done on it. > * Some other people have contributed patches, and this has helped. > * For my use case, I've had to do some debugging and back porting of some > updates to ClojureScript, to cljs-in-cljs: > - CLJS-417 (js-mod, type compat) > - CLJS-495 (defmaco exists?) > - CLJS-613 (try/catch form) > - clojure@1d1a812 (float compat) > * I have contributed the above as pull requests, but it appears that Mr. > Martin is busy with graduate school. These updates and fixes allow me to > run C2 and most core.async functions. This branch is available at: > Link: https://github.com/wbrown/clojurescript > > Today, I had been working on a merge of ClojureScript HEAD into my > cljs-in-cljs branch, but it's so far out of date that it's a huge headache > to untangle. I threw my hands up when the emitter could not understand > `null`. I am leaning strongly in the direction of starting afresh with a > stable and recent cljs release, and using Mr. Martin and Mr. Houser's work > to inform me of directions and to give hints. > I realized that cljs-in-cljs actually is already self-hosting after looking at it again. An impressive feat! Still, I would imagine that maintaining it out of tree must be pretty time consuming, given the pace of cljs development. The main draw of cljs-in-cljs for me is being able to do rapid prototyping > and development in the browser itself, without any external server > dependencies. I tend to think much more incrementally in terms of project > scope, so I am thinking, 'cljx-ify cljs;. > > The first few steps of this would be: > * Unify `cljs/reader.cljs` and `cljs/reader.clj` into `cljs/reader.cljx` > -- this is expedited by the work that Mr. Houser and Mr. Martin did to > implement function reading in there. > How about this? - Update clojurescript to use clojure.tools.reader - Add a cljs port to clojure.tools.reader, based on existing work Even if you decide to move forward with cljx, those two are independent, easily done and likely to be accepted + the best cljx code are dependencies ;-) > * Polish and paper over the Java hard dependencies in `cljs/analyzer.cljs` > revolving around File I/O, and the PushbackReader into > `cljs/analyzer.cljx'. This will require more integration of the changes > the previous authors did. > * Take a look at `compiler.clj` and cljx-ify that as well. > * And more, such as updating repl.cljs, etc. > > This is a pretty incremental step, and I think it would help go in the > direction of the unified compiler emitter that you mentioned. cljx-ifying > cljs would help highlight where the hard dependencies are in JavaScript and > Java. > However, would the community accept such a cljx-ified beast into the > MASTER branch? I would not want this work to end up on a shelf, to bit rot. IMO as a community member + It would mirror current clojurescript's usage of gclosure as a post-processor - clojurescript's build process is complex as it is, adding a pre-processor won't help that - cljx isn't contrib (k.o. in and of itself, would have to be side-stepped by creating a contrib or adding cljx to clojurescript) My primary interest is having a more up to date self-hosting implementation. I think the recent tools.{analyzer,emitter} push brought clojure pretty close to self-hosting. So for such a plan, I would try to take advantage of those and maybe even add clojurescript ports (I suspect that they wouldn't differ much, except macro usage). > That's a really good question -- for me, self-hosted means being able to > compile and build from within the environment itself. With Mr. Dunlop and > my work on Mosquito Lisp, we achieved this -- but the low level bits are > not written in Mosquito Lisp, so there's some similarity there. I know > that Clojure and ClojureScript rely on the rich environment of Java and > JavaScript/Closure so they are by no means low level environments. > > Reading your exploratory writing, I'd already been thinking in the > direction of a JavaScript optimizer. The reliance on Closure to post > process the compiled JavaScript output is a huge speed bump in the road to > cljs-in-cljs. > > I'm not discouraged at all by your post -- I am just wondering and trying > to figure out if steps 1 and steps 2 is going to be less work for me than > the steps outlined. It's certainly the more correct way. > The fun thing is, as soon as you have clojure.tools.{analyzer,emitter} in clojurescript, you can ignore the whole settlement process about compilation models completely and just fire up a customized repl at any time. The bottom line to me is: a cljx dependency is unlikely to be committed to any core project, but there are multiple precedents for supporting both clj and cljs versions in the same contrib. cljs-in-cljs is also built in this style, currently. kind regards -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
