How does one fix a macro like this? https://gist.github.com/borkdude/145d9433d9e8cc386d40495849b0b3c8

@borkdude bear with me here

does it work if you add a (def foo 42) in repro.macros?

I think you need your macros to be in clj files

cljc files work just fine

no

I have a workaround for this, but I’d like to make sure if there is no better way

workaround looks something like:

(defmacro with-instrument-disabled [& body]
    `(choose-env :clj
                (clojure.spec.test.alpha/with-instrument-disabled ~@body)
                :cljs
                (cljs.spec.test.alpha/with-instrument-disabled ~@body)))

oh right

where choose-env is:

(defmacro choose-env [& {:keys [cljs clj]}]
    (if (contains? &env '&env)
      `(if (:ns ~'&env) ~cljs ~clj)
      (if #?(:clj (:ns &env) :cljs true)
        cljs
        clj)))

I know this works, but I don’t know why this works 🙂

well there’s no runtime clojure.spec.test.alpha in CLJS

@borkdude An alternative is to rely on ClojureScript runtime clojure.* namespace aliasing, and require macro clients to require clojure.spec.test.alpha via that name. It is not perfect, but by making that concession, it leads to simpler code and uniform usage. https://gist.github.com/mfikes/cef096f0b44018014d9939c67f668ec1

@mfikes thanks. do you have an intuition what is the common way of handling this in other related libs?

maybe not a lot optimize for REPL usage?

I haven't looked at the source for libs that attempt to do this. But, I do feel that sometimes people try to get away with a single *.cljc file (for good reasons), but that may make things more complex.

if I put these macros in a .clj file, then I would have to define some functions that are used in the macro twice, once in the .clj file and once in the .cljs file?

or can you have a .clj, .cljc and .cljs file with the same name?

If you have all three files, I suspect that the *.cljc file would never be loaded, according to the rules.

If the macro expands to make use of helper functions, then perhaps those could be placed in a *.cljc file associated with another (impl) namepsace.

I guess making the convention for REPL usage to do the require first is OK. It would only have impact on REPL sessions, not project code, I guess?

right

but some functions are not impl, they are public API.

There is no difference between the REPL and project code in terms of the need for client runtime namespaces to require clojure.spec.test.alpha by that name, for the approach example I provided.

but these can be re-def’ed from impl to public ns maybe

@mfikes would there be any downside of imposing this require clojure.spec.test.alpha on consumers?

It is really just an annoyance.

@borkdude And, truth be told, it requires your library clients to be on ClojureScript 1.9.198 or later

@mfikes what happens in JVM cljs if I put a defmacro in a .cljc not within a #?(:clj …)? It works and I see no difference in the tests. Putting it within the conditional doesn’t work on planck.

If a macro is compiled by ClojureScript, it produces a function

and if you put a :require-macros to the ns with a refer to the macro?

I'm just saying, when a (defmacro ... ) form is compiled, if the ClojureScript compiler is the thing doing the compilation, you get a function instead. This is because defmacro is itself a macro that expands to involve defn. In self-hosted ClojureScript, that function is called at compile time if it is being used as a macro.

Outside of self-hosted ClojureScript, you generally would only have defmacro forms being compiled by the Clojure compiler.

Forms in .clj files will end up being compiled by either the Clojure compiler, or the ClojureScript compiler (in the case they are being required as macro namespaces by self-hosted ClojureScript). Forms in .cljc files follow the same rules essentially, with the added rule that you can force some forms to be in either :clj or :cljc branches of reader conditionals if you wish.

Going back to your original question, the answer is that Planck, being self-hosted, is compiling the *cljc file with the ClojureScript compler, and thus it takes :cljs branches.

Looking at Clojure, the bit about defmacro producing a function appears to be true in Clojure as well.

I think it’s still unclear to me what the behavior exactly is when I require a .cljc file with a macro in the top level (no reader conditionals) from a CLJS file

hey… i’m playing around with clojurescript, and wanting to create a multi-method that dispatches on every clojurescript datastructure and primitive type. Obviously I can use a dispatch function of type but I’d rather not dispatch on concrete types but rather the abstract types (identified by protocols), e.g. IMap, IVector etc… Is there a way to ask a value for all of the protocols that are extended to it; or some other way to do this?

is that (defmacro foo now a defn? will it show up in my bundle? what exactly happens if I try and call it?

@rickmoynihan I think a multi-method is the wrong tool. you’d probably want to use protocols and extend-type

I could certainly do that too… but I don’t want to extend every concrete type.

sounds like you do tho? :P

@lilactown @mfikes > Looking at Clojure, the bit about defmacro producing a function appears to be true in Clojure as well. that bit wasn’t 100% clear to me either. In JVM Clojure (not CLJS) a top-level defmacro in .cljc will become a function?

you can use extend-protocol to get rid of some of the boilerplate

@borkdude If you require the *cljc file as a runtime namespace (not a macro namespace), yes.

cljs.user=> (set! *print-fn-bodies* true)
true
cljs.user=> (defmacro foo [bar])
#'cljs.user/foo
cljs.user=> foo
#object[cljs$user$foo "function cljs$user$foo(_AMPERSAND_form,_AMPERSAND_env,bar){
return null;
}"]

If you require the *.cljc file as a macro namespace, then it will be compiled by Clojure, and Clojure does what it does with macros (compiles them to a function the compiler can call)

In that second case, the JVM ClojureScript compiler can also use that macro.

Perhaps there are so many variables at play that, really to avoid confusion, you almost need to provide a minimal bit of code along with a question 🙂

@mfikes ah, you were talking about cljs in that line. so when not using cljs, it just behaves as a normal .clj file… just checkin’ 😉

thanks for the elaborate response

Yeah, sorry, it is difficult to generalize without getting some aspect wrong.

On one hand, you have the semantics of macros, which involves how they are compiled, and how they are used. And on the other hand, you have *.clj, *.cljc, *.cljs semantics and how they are required

I can imagine a 2 or 3 dimensional table descrbing what happens.

Add to that the fact that ClojureScript supports macro-functions, and in that case, the one you get depends on whether it is in operator position or being passed as a higher order function.

such a dimensional table would be an awesome piece of documentation

It feels a bit like the JCiP book, where the truth is baroqueishly complicated, but, if you stick to a subset of patterns, you can keep it straight. But, like anything, when it breaks, it is good to have an understanding of the truth.

is this discussed in the clojure macro book maybe?

I don’t know if cljc already existed when that got written

Colin’s? He doesn’t even really discuss ClojureScript IIRC.

It is an awesome book regardless. I think I’ve read it 4 or 5 times :)

I think I’ll read it when he updates to cljc 😉

neh, I think I’ll read it regardless. but having a guide on macros in cljc would be superb

To be honest, I ended up writing http://blog.fikesfarm.com/posts/2018-08-12-two-file-clojurescript-namespace-pattern.html as a “JCiP-style-simplification” guide to the way I like to write macros for ClojureScript projects. (While ignoring the possibility of use from Clojure.)

yeah, that’s the thing. what if you also wanted to use this from clojure, where would the defn go?

I guess you could then move that to the .cljc impl file

I don’t think enough people are writing portable libraries to have discovered any best practices—it always seems to result in some compromise.

if that were all, then I would do that. but what if lib.core also exposes normal defns for public usage.

ok

Take a look at core.async (which doesn’t address self-hosted), specter, test.check, quil—they all seem to adopt more or less of a mess to pull it off. None are clean in the end.

test.chuck also

It seems that if you want to target all three platforms, you need to be prepared for some funky code, no matter how you slice it.

ok. that’s what I wanted to know, now I don’t have to feel guilty 😉

The trick IMHO, is to keep the complexity and mess inside the lib. That way it works the same for all client code.

yeah, that’s what I was trying to accomplish.

so not imposing an extra require on the user was kind of my goal

Indeed—you can avoid that and push the complexity into the lib.