I believe that you're absolutely correct in that the right design approach is
having an unified targeting compiler rather than using feature expressions in
cljs.
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.
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.
* 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. My
primary interest is having a more up to date self-hosting implementation.
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.
-Wes
On Sunday, May 18, 2014 8:46:13 PM UTC-4, Herwig Hochleitner wrote:
> I think cljx is a great tool to paper over subtle differences in the
> languages, that two compilers (like clj and cljs) accept, for use in projects
> that would like to treat those compilers as black boxes (i.e. almost all
> projects).
>
>
>
>
>
> A new compiler (one that could compile itself to javascript, hence dubbed
> cljs-in-cljs), however, is an opportunity to unify the accepted language,
> such that it can target java byte code, javascript, variants thereof, aswell
> as other platforms, without the need for an external preprocessor like cljx.
> It's very well possible that such a unified implementation will support
> feature expressions in the reader and that they will look like cljx does and
> if we can get all the CAs, it might even use code from cljx.
>
>
>
>
> I also think that just doing a straight port of cljs to feature expressions
> is the wrong focus for now. Here are a couple of next steps that seem logical
> to me:
>
>
> - create clojure.tools.emitter.ecmascript from the clojurescript compiler
>
>
> - update clojurescript to use clojure.tools.analyzer and clojure.tools.emitter
> - extend clojurescript to allow it to emit jvm byte code (from
> clojure.tools.analyzer.{jvm,ecmascript})
> - implement clojure.lang in clojure using swaths of cljs.core
>
>
>
>
> Steps 3 requires a design, that is not present in either clojure or
> clojurescript: an explicit model of the (compilation) target platform.
> In clojure, this is currently hard coded to a tasty blend of #{load whatever
> is on the classpath, emit ns/fns to jvm classes with asm, uniform ABI at
> namespace level to allow additive loading}. For clojurescript, add/substitute
> #{find macros in dual clj namespace, emit ns/fns to gclosure packages}.
>
>
> A compiler aiming to support multiple platforms should make it easy to switch
> out or configure any of those.
>
>
> For me this raises a pretty hard question: What should the concept of
> "self-hosting" mean in a "hosted language" like clojure?
>
>
>
>
> What do you think of this assessment?
>
>
> kind regards
>
>
> P.S. I've done some exploratory writing on this in the past:
> http://dev.clojure.org/display/~bendlas/Design+for+compilation+units+in+ClojureScript
>
>
>
>
>
> 2014-05-18 21:50 GMT+02:00 Wes Brown <[email protected]>:
>
>
> So I've been taking a look at bringing my fork of cljs-in-cljs of to modern
> ClojureScript.
>
>
>
> After going through diff logs, the task of bringing kanaka's cljs-in-cljs
> fork up is pretty daunting, especially as one would have to maintain separate
> cljs and cli forks of the same analyzer and compiler duo; this explains his
> comment about compatible changes.
>
>
>
>
>
> Upon examining the Feature Expressions in Clojure situation, I was pondering
> whether cljs-in-cljs could instead be a modification of the Clojurescript
> code base that uses `clix` to shadow the differences?
>
>
>
> However, cljs-in-cljs does understand macros, and this isn't supported by
> `clix`.
>
>
>
> I'd be interested in feedbacks and thoughts -- it would be a useful exercise
> to cljx-ify the CLJS compiler and analyzer written in Clojure, using some of
> the changes and code that chouser and kanaka did.
>
>
>
> -Wes
>
>
>
> --
>
> 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.
--
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.
