Skip to content
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

Open
kylecordes opened this issue Sep 23, 2014 · 7 comments
Open

Request for CLJS version doc #82

kylecordes opened this issue Sep 23, 2014 · 7 comments

Comments

@kylecordes
Copy link

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.

@jeluard
Copy link

jeluard commented Sep 23, 2014

I noticed a bunch of warnings with latest ClojureScript 2342 version:
WARNING: Use of undeclared Var dommy.template/->node-like at line ...

@kylecordes
Copy link
Author

I saw that also, and noticed there was nothing here about versions - hence this item.

@atroche
Copy link

atroche commented Sep 25, 2014

Same issue here

@p-b-west
Copy link

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.
attrs use(s)-macros macros :only node

The "node" macro from macros generates code which calls ->node-like
->node-like is defn'd in template.

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.

@loganlinn
Copy link
Member

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

@p-b-west
Copy link

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?

@loganlinn
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants