https://clojure.org/guides/faq#illegal_access

Virgil's original repo is not maintained anymore. Please try the maintained fork: https://github.com/clojure-goes-fast/virgil. Note that it doesn't have a lein plugin, you are supposed to add it as a runtime dependency and invoke manually (see README)

🙏

thank you @U064X3EF3 and @U06PNK4HG

FYI: Zach just transferred virgil to clj-commons -- @U06PNK4HG would you be interested in becoming the official maintainer under the clj-common org, and bringing the underlying repo up to date with your fork? Happy to discuss further in #CE1A21MPF

These two statements contradict each other: > I'd rather not do the checking at runtime. > a macro that expanded to the right thing at runtime since such a macro would still rely on a run-time check. > It seems that I'd have to set the atom before requiring the library with the compile function in it. > Is that right? Yes. > I set from a CLI -d option. If you switch to Java properties or environment variables (both of which you can use with CLIs), you can make it work without having to be careful about namespace loading order.

I meant I'd rather not have compile function that checks for the debugging of each stage at runtime, for every invocation of the compile function. I want to macro expand the function once at runtime to DTRT. I already need to decide with of the 2 highly similar functions to call at runtime.

I'm asking because I need to add other options to this function and don't want a matrix of similar functions... I think for now I'll just collapse it to one compile function that checks behavior at runtime. iow, not prematurely optimize until it's an issue

You don't have to decide every time:

(if debug?
  (defn compile [...] ... debug impl ...)
  (defn compile [...] ... regular impl ...)

https://github.com/yaml/yamlscript/blob/main/core/src/yamlscript/compiler.clj#L29-L96 are the functions, called here: https://github.com/yaml/yamlscript/blob/main/ys/src/yamlscript/cli.clj#L280-L284 Getting rid of the -d option is not something I want to do. I use it constantly. I see what you are saying but what I want to get to is to DRY out compile to one function, not 2. And I'm about to add more options. I was thinking a macro might be useful to expand to the right thing, but likely it would be more convoluted to read. I guess for any new options I can just add them to the debug version, and stay at 2 implementations: compile-normal and compile-with-options.

An alternative is to start being careful avoid namespace loading. One more or less trivial solution is to have a "wrapper" namespace that's the main entry point and that doesn't use :require to load other namespace but rather uses requiring-resolve to require, resolve, and call some other entry point after all CLI options have been parsed and all global flags have been set. I don't have time at the moment to properly study your code, but it seems that you're already passing opts around so I don't know what that global atom that you've mentioned is or why you'd need it. Passing opts around is probably the most direct, simple, and robust way to handle things. To avoid repeating things across compile implementation, you can employ regular refactoring techniques - you can combine it into a single function that checks opts itself or you can split the functionality into many smaller functions that compile and compile-debug would call, maybe conditionally.

I'll look into the requiring-resolve technique at some point. I don't use atoms much, but keeping the parsed CLI options in an atom mapping to be accessed from anywhere in the code without needing to refactor that code feels right to me. And yes, there is a little more refactoring I can do to dry out the compile and compile-with-special-options functions. Thanks for the help 🙂