core is direct-linked when AOT'd so I'm surprised you can redef first tbh

I notice that first is defined through a def and inc is defined through defn. idk if that makes the difference (yet)

looks like it might

next is def'ed as well

(with-redefs [first dec
              next dec]
  [(first 5) (next 5)])
=> [4 4]

Looks like with-redefs was introduced in Clojure 1.3 but for 1.3 through 1.7 that code throws an exception:

=== 1.3 ===
Exception in thread "main" java.lang.ClassCastException: class clojure.lang.PersistentArrayMap$Seq cannot be cast to class java.lang.Number (clojure.lang.PersistentArrayMap$Seq is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')
        at clojure.lang.Numbers.dec(Numbers.java:118)
        at clojure.core$dec.invoke(core.clj:1082)
        at clojure.core$with_redefs_fn$root_bind__5911.invoke(core.clj:6477)
        at clojure.core$with_redefs_fn.invoke(core.clj:6485)

There's nothing in the docstring or on clojuredocs that suggests to me that clojure.core vars are exempt from the effect of with-redefs

Direct-linking in AOT generally means that if you redefine a symbol, but don't redefine each caller, the redefinition "won't be seen", because the var-lookup at the call site is omitted and the original version of the function is emitted in the bytecode.

I suspect the def vs defn is a quirk that circumvents the direct-linking substitution of the function...?

You tell me. I don't know nearly as much about these concepts as you do 🙂 I was just trying to show a junior coworker something and was surprised when with-redefs basically didn't work as documented. Your explanation hints at an edge case, or at least an explanation that is more complex than would normally fit in a docstring, so I "get it"... I just don't like surprises like that 🙂

Trying to redef core fns is a Bad Idea(tm). with-redefs is a pretty problematic thing anyway since it's not thread-safe, as I recall, so it really should only be used in tests and even then only in limited situations, on your own application code.

Well, 3rd party libs might be "ok" too since they shouldn't be AOT compiled.

Yeah, I see how it could create problems to with-redefs core fns. I thought that I could do it for fun and demonstrations in REPL play, though, and the clojuredocs examples seemed to support my thinking.

I wonder if those clojuredocs examples predate direct-linking AOT for core? I don't remember when that changed.

Thank you for the enlightenment, @U04V70XH6 🙂

@U04V70XH6 do you have a good source where I could read up on direct-linking AOT for core? Is it in the changelogs, or maybe there's an article explaining the motivation or something? I know very little about the innards of core and haven't cared (much) about the innards of Java/JVM for ages, so I could do with some education. I understand what AOT is from an abstract perspective, but I don't understand direct-linking and the relation to clojure core.

https://clojure.org/reference/compilation#directlinking

LMK if that doesn't answer your Qs @U0AQ3HP9U

Thank you very much, that clears up quite a bit, @U04V70XH6 ! 💪 🙏