@U04VDQDDY Does that still work in the self-hosted context?

Yes

In order to compile f, it has to macroexpand the m inside it, which simply expands to a call to f.

After macroexpansion, it would look like

(defn f []
  (when (< 0.5 (rand))
    (foo.core/f)))

Hmm. So, when I do this in practice I'm encountering an issue.

Maybe provide a minimal repro / gist.

Yes. 😅

@U04VDQDDY I think I might be misunderstanding how self-hosting works. In order to make that self-hosting compatible do you need to make core.clj a .cljc file?

No

Okay, there's definitely something wrong with my mental model of how self-hosting works, then.

Self-hosted ClojureScript will happily load a .clj file with macros in it. (It will, of course, compile that .clj file with the ClojureScript compiler.)

So the .clj file has to be valid ClojureScript, but it doesn't need to be in a .cljc file?

The reason for this is so that regular ClojureScript libraries that use .clj files for macros will be compatible with self-hosted ClojureScript.

Right. It is odd, but true. 🙂

I see!

That's extremely helpful.

Thank you so much!

Reference: https://github.com/clojure/clojurescript/blob/73272a2da45a4c69d090800fa7732abe3fd05c70/src/main/cljs/cljs/js.cljs#L84-L85

I see. I had wondered why :cljs wasn't an option for the map load-fn provides its callback.

The intent is to, if at all possible, and within reason, prevent self-hosted ClojureScript from being a "fork" of ClojureScript, needing completely different codebases, etc.

That makes sense!

Oh, yeah, in that case, the :clj in the return for load-fn really means "ClojureScript". 🤪

I see!

In the project that spawned this question the file with the macro is a .cljc file.

I suspect that's where I went wrong.

The example I gave above could have used a .cljc file instead of .clj and it would still work the same, FWIW.

Would it work with both the function and the macro in the same .cljc?

Ahh, you had to go there!

Hah.

😆

OK, I think so. Let me see if I can write a variant like that...

What I'm finding is that if another .cljs file :require-macros the combined .cljc namespace and calls the macro it triggers a runtime error about the function not being defined.

Here is a single-file example, not worrying too much about double-definitions, etc. that works https://gist.github.com/mfikes/5c42494d3174988efb5776434b831a1a

Extending that a little to see if I can repro what I think you are saying...

My core.cljc is identical to yours, just with minimal.core as the namespace.

I added a foo.bar which is a bit like your minimal.core to the gist above

In your example, nowhere do you require the runtime namespace though

I'd recommend using two files instead of putting it all in one. (Just my preference.) http://blog.fikesfarm.com/posts/2018-08-12-two-file-clojurescript-namespace-pattern.html

Sorry, this is the error:

$ clojure -m cljs.main -m minimal.main
WARNING: Use of undeclared Var minimal.core/f at line 6 main.cljs
Exception in thread "main" clojure.lang.ExceptionInfo: TypeError: Cannot read property 'f' of undefined

Yeah, I've read that blog post of yours. (Thank you!) I just didn't realize that I could use .clj files in the self-hosted context!

With that recommendation, minimal.core wouldn't do :require-macros. In fact, you end up never really using :require-macros except when a cljs file does that on its own macros namespace.

Anyway, regardless of that recommendation, the reason your code is failing is because your code never requires the runtime namespace which defines f.

Yes.

If foo.bar :requires foo.core it works fine.

But I'm worried about the usability implications of that.

How should clients know that they have to require more than just the macro if the macro is all they're using?

See what I mean?

Right. Me too. The "Two-File" approach is extremely useable, from the consuming namespace perspective. It practically looks like Clojure where you just require the namespace and refer symbols from it, without regard to whether they are fns or macros.

I'll give that a shot!

I think the relevant bit from that post that addresses your usability concern is the paragraph: > Notice that in the above, we simply required the lib.core namespace and used the macro. We didn’t need to use :require-macros or be concerned about whether reverse-lookup is a macro or a function, or that it uses a runtime function from the lib.core namespace.

If we had used :require-macros would it have blown up?

Yeah, because you are essentially only loading the "macro half" of that namespace, if you will.

I see, I see.

The really nice thing about this pattern is you simply require the namespace, and use its vars. Simple.

Whereas with .cljc files you can't do that? You have to use :require-macros?

Any complexity surrounding whether vars are macros, whether two file are used, etc, is pushed onto the implementing namespace. (The client consuming namespace need not be concerned.)

Interesting.

Well, you could take the two-file pattern which involves .clj / .cljs and try to cram it into a one-file pattern that just uses .cljc

I mean, it need be concerned with using :require and not :require-macros, unfortunately, right?

But then you end up wanting Macrovich or Chivorcam.

I saw Macrovich, and was considering it. 😩

Hmm. As a client of macro namespaces how do I know when it's safe to :require-macros?

FWIW, the gist https://gist.github.com/mfikes/5c42494d3174988efb5776434b831a1a is essentially the two-file crammed down to a one-file. I commented out the :require-macros in the client foo.bar namespace and it works fine.

Roger that.

So, you are worried about the situation when you are using a macros namespace and you use it by doing a :require-macros on it, only to find out that the macros namespace expands to use some runtime functionality that was never required.

My answer: Use the two-file pattern, and just require the runtime namespace. The two-file pattern lets the implementing namespace take care of whatever it needs to have loaded at runtime, etc.

I guess, I'm arguing that the two-file pattern is an example pattern that makes it easy on clients.

But as a client I can't know whether a given library is using the two-file pattern without seeing its source, right?

I buy your argument that the two-file pattern makes life easy, for sure. 🙂

I didn't invent the two-file pattern 🙂 I just wrote a post about what I saw as a good practice in the ClojureScript's core libraries and other places.

I see, I see.

Right, indeed, as a client of any namespace, if that namespace chooses to try to do funky stuff, they have to document up the wazoo to explain to you how to use it.

Would you say that use of :require-macros is dangerous, then, if you don't know whether a library you want to use is is using the two-file pattern or not?

That's a good question...

I'm leaning that way, but I'm new to this.

To put that another way: Clients don't know whether a macro-providing namespace has both runtime and compile-time elements.

Two example libraries that I can think of that include in their documentation specifics regarding macros are test.check and the need for :include-macros true and Quil, which does the same.

I see.

Kind of a bummer that that's necessary.

core.async used to be a little funky to use, but that has since been straightened out over time and now you can use core.async in ClojureScript just like you would in Clojure.

Here is core.async essentially employing the two-file pattern https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async.cljs#L9

If you do (doc ns) the two-file pattern is described in teh paragraph with the heading "Implicit macro loading"

It sounds like the best practice for clients in the absence of explicit advice is to try getting the macro symbol with :require first, maybe.

:thinking_face:

Yeah, cljs.test, cljs.spec, core.async work this way, nothing to explain.

(And as an aside, you can refer to them as clojure.test, clojure.spec, clojure.core.async, as well, which is nice.)

Good to know.

I suppose the truth is, no matter what namespace you run into, you might end up needing to read its source if it deviates from that pattern.

Yeah?

I don't fully understand yet when :require fails.

So, you have a valid concern with respect to the question of "How do I generally consume a ClojureScript namespace that might involve macros, if I don't know if it follows the two-file pattern?"

I don't have a good answer to that. I would hope that good popular libraries just figure this out somehow and write things this way, but that is probably unreasonable to expect. That's partly why I ended up writing that post, I suppose. I kept trying to spread the good word, and finally just put it into a post.

In some sense, this macro stuff reminds me a bit of C++. In C++ there are lots of things you can do, but over time, the dev community settled on using a subset of that, honed over time as being best practices. That subset is a bit more sane and easy to keep in your head, grok, etc. Same thing is true with macros in ClojureScript. I think a lot of people naturally want to shove both runtime and macros into a single cljc file because that seems to get you closer to Clojure. But, I've personally started to appreciate the two-file (implicit macro loading) pattern as just being simpler, even though things are spread across two files.

It sounds like the only situation where :require fails is when the macro is in a .clj file, and there is no corresponding .cljs file. Does that sound right @U04VDQDDY?

Yeah, you need to have at least a stub .cljs file to follow the two-file pattern.

So "Try :require first, fall back to :require-macros" should work as general advice. :thinking_face:

Yeah, if you are just trying to use a namespace that you are not familiar with, that sounds reasonable.

@U04VDQDDY If you want both f and m to be callable from both and you kind of have to use a one-file self-requiring .cljc file, right?

Yeah, things can get really mind-bending when trying to target that. Macrovich might help you retain your sanity. https://github.com/cgrand/macrovich

Got it. Great! Just checking my understanding.

@U04VDQDDY I'm noticing something strange about the "crammed" .cljc you posted above.

In the self-hosting context the arguments to macro m are still evaluated.

Works fine in regular .

(ns test.core
  #?(:cljs (:require-macros [test.core])))

(defmacro m [& _]
  `(test.core/f))

(defn f []
  (when (< 0.5 (rand))
    (test.core/m do not eval)))

I'm testing it with plk.

@zane When compiling the above namespace as a macros namespace under self-hosted ClojureScript, it is fundamentally first being compiled by the ClojureScript compiler, and the resulting macros can then be used by the compiler. But... that function f sitting there makes a call to m, and at that point (since m is sitting in the same compilation stage as f) m is essentially still a function as far as f is concerned. You can repro this directly in a JVM-based ClojureScript REPL:

cljs.user=> (defmacro m [& _])
#'cljs.user/m
cljs.user=> (m do not eval)
WARNING: Use of undeclared Var cljs.user/do at line 1 <cljs repl>
nil

That makes sense to me. Would I be right to conclude from that that it is not in possible for a macro m to expand to include a call to a function f that itself uses m if both m and f need to be accessible at both macro expansion time and runtime?

I feel like it must be impossible because in order to separate the compilation stages you'd have to create a require cycle.

Hmm. That could be true. The underlying rules are quite simple, but the consequences are myriad. 🙂 Much like the game of Go. My opinion: When you tread into this territory, it is just too hard to figure out.

(I prefer to just keep things simpler, especially when it comes to macros.) Not saying what you are trying to figure out won't work. It just takes more brain cycles to sort out than I have. 🙂

That makes sense. It's complexity I wish I could avoid(!) but unfortunately it's inherent in our domain.

For now we've just inlined the results of the macro call in the function that uses it.

In any case, thank you so, so much for your help, Mike! 🙇:skin-tone-2: