-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for CLJS version doc #82
Comments
I noticed a bunch of warnings with latest ClojureScript |
I saw that also, and noticed there was nothing here about versions - hence this item. |
Same issue here |
The problem, I think, is that there are circular dependencies between the files. From clojurescript 2341, this seems to have been picked up, even though, according to David Nolan, it has never been legal in either Clojure or ClojureScript. template requires attrs. The "node" macro from macros generates code which calls ->node-like I think that is the source of the circularity. I tried to resolve this, but every time I touched anything dommy broke. It's a bit of a tangle in there. As well as that, I don't understand the namespace issues in involved in the path from clojure macros to clojurescript expansions. |
For an update, we have work-in-progress to address these namespace dependency issues (#85). When we release that (sometime this week), we will also document any CLJS version details. Thanks |
Puzzling over the code, I notice that there is a mix of defmacro, def and defn in macros.clj. Mocaros can only be defined in clojure files; fair enough. However, the non-quoted parts of the macros are being compiled in the clojure compilation step. Therefore, the clojure compiler needs defns for, e.g., as-str, which is used extensively, unquoted, in the macro definitions. Consequently, there is a defn for as-str in macros.clj (as clojure.) However, the clojure components are only there to support the macro definitions, which will be called from within the cljs files. Sure enough, as-str has an identical definition in utils.cljs. Isn't this redundant? The fact that clojurescript defmacro must be compiled by the clojure compiler, when there will be no clojure in sight when this code is executed, surely means that there should be no clojure evaluation of the content of a macro definition. For instance, in the cases where as-str is used in a defmacro, as-str should be quoted. In that case, there is not need for the clojure compiler to attempt to resolve a call to as-str; that is left to the clojurescript code that expands the macro. Ot so ti seems to me. Does this make sense to anyone else? Or have I misunderstood something basic here? |
@numinasthmatic Thanks for taking time to read through the source. Indeed, understanding macros can be confusing, especially ClojureScript ones. Not going to go into too much detail here as this is an off-topic subject, but the reason why you would want a function to exist in both Clojure and ClojureScript is to apply optimizations at compile time, when possible, otherwise fallback to a runtime (CLJS) version. This is a common practice. |
Hello. Naturally things are continually shifting when using a stack consisting almost entirely of pre-release software... but it would be helpful to have a few words here (or better yet, in the README) about what version(s) of CLJS Dommy is believed to work with.
The text was updated successfully, but these errors were encountered: