Porting the code to clojurescript
zcaudate opened this issue · 24 comments
How difficult will it be to port the code to clojurescript?
I found this talk which is quite interesting http://www.infoq.com/presentations/clojure-clojurescript
I'll watch that talk once I have a little spare time. However, I assume it suggests cljx for simultaneous clj and cljs development?
rewrite-clj itself is probably quite porting-friendly since it doesn't do a lot of Java interop (with exception of I/O, I guess). Let's have a look at dependencies:
org.clojure/tools.reader: This is used for reading simple tokens. Could be replaced withcljs.reader.fast-zip: A faster zipper implementation. Could be replaced withclojure.zip.potemkin: Used for generating the zipper API facade. Lots of macros. Even if not directly usable, the API can still be exposed manually.
So, I think this can be done with a reasonable amount of work.
it's using lein-dalap instead. its quite an elegant solution. I took a look at fast-zip and its definitely portable too. I'm not sure how potemkin would work though =)
I'm also interested in ClojureScript version.
However maybe you know other way to achieve this:
(prn/print-edn (p/parse-string "(defn my-function [a]\n (* a 3))"))? So I basically want to reformat clojure code in ClojureScript application.
Hi, is this still an interest? I'd be happy to get started on this feature.
That would be most amazing :)
On 24 Aug 2014, at 15:19, john walker notifications@github.com wrote:
Hi, is this still an interest? I'd be happy to get started on this feature.
—
Reply to this email directly or view it on GitHub.
Would you rather fast-zip be replaced with clojure.zip, or that the cljs version use clojure.zip and the clj version use fast-zip?
How are you soon the port? As a seperate project or using cljx?
On 21 Sep 2014, at 1:20, john walker notifications@github.com wrote:
Would you rather fast-zip be replaced with clojure.zip, or that the cljs version use clojure.zip and the clj version use fast-zip?
—
Reply to this email directly or view it on GitHub.
using cljx
I'd go with clojure.zip in this case for both as I don't really have a problem with the speed up for fast-zip and it's neater... @xsc what do you think?
On 21 Sep 2014, at 5:50, john walker notifications@github.com wrote:
using cljx
—
Reply to this email directly or view it on GitHub.
@zcaudate, @johnwalker
First, let me say thanks to you two for persuing this! I currently can't fit it in anywhere...
Regarding fast-zip vs. clojure.zip: It doesn't really matter since they should be drop-in replacements for each other. But since there actually is a PR (akhudek/fast-zip#6) in the pipeline that adds CLJS support to fast-zip, let's make it the eventual thing to be used? (For development clojure.zip is just fine.)
Thanks again!
Aaaand fast-zip has cljs support now :)
One additional (major) problem here is that our tests are using Midje which does not have a ClojureScript port...
+1
Clojurescript support would be really neat !
Thought I'd give you a heads up. I'm currently working on a ClojureScript port :)
The good news is that I haven't spent more than a day or so, but got quite a lot of it up and running. The bad news perhaps is that I've gone down the route of creating a rewrite-cljs rather than the cljx route.
A couple of selfish reasons for that;
- I have no experience with cljx. With cljc gaining traction/maturity that might be a better option in the longer run.
- My primary use case is for using the lib from Light Table to provide clojure/clojurescript refactoring support and perhaps/hopefully better paredit support in LT. LT unfortunately currently uses a very old ClojureScript version, that probably wont change in the very near future.
- My current macro foo is very much non-existing (workin on it) (: All macros would have to be extracted into separate clj files I think, and rewritten to emit only valid cljs when targeting ClojureScript. I haven't really had any time yet to see consider how one would best address that
- Although I want to make sure I can use the lib from LT, it should of course still not be tied to that in any way, so if someone would like to use the lib from any clojurescript app, they should/would be able to
Since I haven't really commited that much effort into it yet, It's not to late to turn the ship around though.
Several options and I'd like to hear your thoughts !
- I continue with a rewrite-cljs (obviously refererring/linking to rewrite-clj). Full freedom for my part, but gives me the headache of trying to keep the lib up to date with your lib. Lot's of duplication etc. Even if we go down this path, I suppose we should/could have the long term goal of back-porting
- Opt for cljx. Pull request from me, and you would take ownership of ClojureScript support. (I'd still be contributing given this route of course). A few challenges here though;
- Probably quite a bit more effort from me
- You would have to be willing to take on the extra effort of supporting cljs !
- To keep ones sanity I suppose moving from midje to clojure.test or perhaps expectations for testing might make sense (quite a bit of effort initially ?)
- I had to hack the clojurescript reader to support an IndexingPushBackReader ( I used https://github.com/kanaka/clojurescript as a starting point). I saw a tweet from David Nolen yesterday asking for contributions on supporting cljs bootstraped in JS. I guess this would mean potentially a better reader might surface in the not to distant future among other things :)
- Opt for cljc. Perhaps the most futureproof option
- would limit both clojure and clojurescript version support
- many of the same challenges as cljx
Let me know what you think !
cheers
Magnus
@rundis I'd say, go for a 'rundis/rewrite-cljs' (maybe forking this repo so the necessary changes are documented?). Once Clojure 1.7. is out and adoption increases we can have another look at the cljc way.
Thank you for taking that matter into your hands!
Cool !
You can track the progress of your lib's lesser sibling here: https://github.com/rundis/rewrite-cljs
Now that we have both .cljc and a cljs port of tools.reader, any thoughts on moving this forward? As I understand it, .cljc will break compatibility with clj <1.7, and midje will need to go.
Maybe rewrite-cljc deserves its own project?
Now that we have both .cljc and a cljs port of tools.reader, any thoughts on moving this forward? As I understand it, .cljc will break compatibility with clj <1.7, and midje will need to go.
I'm using rewrite-clj in refactor-nrepl and I'd love to see support for consuming cljc files.
Maybe rewrite-cljc deserves its own project?
Most the community has opted to adopt cljc without worrying about consumers running other versions of clojure. Given that, I don't think the extra effort is warranted. I tried keeping refactor-nrepl backward compatible but that was completely hopeless if I ever wanted access to new functionality. Thankfully upgrading clojure to a new version is relatively painless, given core's attention to backward compatibility.
@xsc The world has moved on and Clojure 1.7 and ClojureScript 1.7 is starting to become more and more mainstream. Maybe it's time to bring ClojureScript support to rewrite-clj.
I think it's worth considering bringing rewrite-cljs back into rewrite-clj (where it belongs imho). rewrite-cljs has had it's place up until now, but it seems wasteful to continue duplicating efforts.
The two projects have diverged somewhat over time, but in essence they are mostly still similar.
what are your thoughts ?
@rundis I agree that adoption has spread and there's nothing speaking against integrating the ClojureScript version (and the Clojure version has generative tests now which should be easier to port to CLJS than the midje ones).
As I wrote in another ticket, I'm currently re-evaluating my projects. Now, rewrite-clj, I wrote it for a specialized purpose - upgrading dependencies in project.clj files - which is covered by the existing functionality; so I'm not as invested in further development as I probably should be. I feel this provides a frustrating experience both to contributors (who I'm very much indebted to) and me.
So, I'll just ask: Seeing the awesome work you've done for rewrite-cljs, would you want to take over this project?
@xsc Sorry for the late reply. I've got to think this through. Since I did rewrite-cljs I've sort of joined the Light Table open source team and have to consider how to handle my already limited spare time.
When I find a chunk of time I can have a shot at bringing rewrite-cljs back into rewrite-clj. If that works out and I feel relatively confident about the codebase in rewrite-clj I'll reassess. If you find someone else willing and capable to take over rewrite-clj that's great :-)
Can this ticket be closed?