Clojure Q&A - Recent questions tagged clojure

"Nested" vs "lateral" exception causes

Sun, 05 Apr 2026 14:18:26 +0000

Currently, clojure.core/ex-info must take a msg and data map, and may take a cause, which must be another Throwable, which may have its own cause, etc. etc..

This supports the case of "nested" exceptions quite well, e.g. in the case of compilation exceptions being caused by macroexpansion exceptions, potentially with their own cause, and works well for fail-on-first-problem situations.

There's also the situation of "lateral" exceptions, e.g. in the case of test runners or static analysers, which is not supported. In this case, if we take lazytest as a concrete example, the test runner throws an exception if any of the test cases it runs throws an exception, but the overall cause of the overall exception, conceptually, is all the individual exceptions.

Currently, the only to do this is to make some bespoke thing in the data map.

I propose changing clojure.core/ex-info to take [msg map & causes], which would be a non-breaking change (or, while we're at it, make the map arg optional as well and default it to {}, but that's a separate topic).

That leaves the question of how to handle ex-cause. To my understanding, to change it to return the cause or the list of causes, would maybe be a breaking change for general exception handling libraries or something, but would not imo pose any significant problem. Alternatively, we might have ex-causes to always return a list, and change ex-cause to (comp first ex-causes).

Any thoughts? I don't trust myself to spearhead a PR alone on this but I'd love to contribute, certainly the pure-clojure side of things seems straightforward enough (and I'd love to patch this into lazytest, but that's again a different topic).

Optimize `eduction`

Fri, 03 Apr 2026 14:25:17 +0000

Problem statement

Eduction is useful part of the transducer ecosystem, which has a benefit/aim of improved performance. However, the function eduction only has a single varargs arity, which adds multiple function calls and and seq traversal allocations.

As seen in this PR to clj-kondo, manually passing in an xform directly can improve both overall performance and lower allocations.

Proposal

Adding arities to eduction can sidestep those allocations and seq traversals, improving baseline performance of all eduction invocations.

(defn eduction2
  {:arglists '([xform* coll])
   :added "1.7"}
  ([coll] (->Eduction identity coll))
  ([f1 coll] (->Eduction f1 coll))
  ([f1 f2 coll] (->Eduction (comp f1 f2) coll))
  ([f1 f2 f3 coll] (->Eduction (comp f1 f2 f3) coll))
  ([f1 f2 f3 f4 & args]
   (->Eduction (apply comp f1 f2 f3 f4 (butlast args)) (last args))))

Missing protocol error will hang on infinite `(range)` input in ClojureScript but not Clojure

Fri, 03 Apr 2026 11:16:47 +0000

functions like transient, assoc, etc will throw helpful missing-protocol error when receiving invalid input but it will hang if it receives infinite (range).
this is related to issue below
https://ask.clojure.org/index.php/14578/even-range-hangs?show=14578#q14578

however, missing-protocol only hang in clojurescript but not clojure so I am wondering if this difference is intended.

example calls that should throws
- (transient (range))
- (assoc (range) :a 1)

Does Clojure have an anti LLM code contributions policy? Would it make sense for Clojure to adopt one?

Sun, 29 Mar 2026 13:14:25 +0000

LLM use appears to have a bunch of ethical and practical problems, the most pressing one seems to be the plagiarism that seems to be pretty excessive even for code and even when not baited:

Video clip of apparently a lawyer live demoing what seems to be Co-Pilot plagiasm

I don't know anything about law, but the lawyer at one point says: "This is a copyright infringement." I've also found this: https://www.twobirds.com/en/insights/2025/landmark-ruling-of-the-munich-regional-court-(gema-v-openai)-on-copyright-and-ai-training It seems to talk about "fair use" of AI model training.

Also see this high-profile incident: https://www.pcgamer.com/software/ai/microsoft-uses-plagiarized-ai-slop-flowchart-to-explain-how-github-works-removes-it-after-original-creator-calls-it-out-careless-blatantly-amateuristic-and-lacking-any-ambition-to-put-it-gently/

Also this field study that appears to be putting the plagiarism rate at seemingly at least 2-5%: https://dl.acm.org/doi/10.1145/3543507.3583199

This article mentions a study that apparently puts the plagiarism rate at 8–15% as a minimum for the easily detectable kind: https://www.theatlantic.com/technology/2026/01/ai-memorization-research/685552/

I don't know what this means legally, but at least morally and ethically this seems sad.

Apparently, some people in the Clojure space already spoke out against LLMs, but I wasn't able to find any anti LLM policy. If there was such a policy, I would expect it to be mentioned in the following places:

I simply wanted to suggest that perhaps the project may want to adopt such a policy.

Here are some other projects that have already done so: Asahi Linux, elementaryOS, Forgejo, Gedit, Gentoo, GIMP, GoToSocial, Löve2D, Loupe, NetBSD, postmarketOS, Qemu, RedoxOS, Servo, stb libraries, Zig.

My deepest apologies if there already is such a policy, or if I'm asking in the wrong space.

Why doesn't defn also implicitly name the anonymous function it defines for recursion?

Sat, 21 Mar 2026 13:49:43 +0000

Why doesn't defn implicitly name the function to create a named recursion point?

(clojure.walk/macroexpand-all
  '(defn foo [x]
     (foo x)))
; =>
(def foo
  (fn*
    ([x]
     (foo x))))

This could instead expand to

(def foo
  (fn* foo ; note the foo here
    ([x]
     (foo x))))

How it works right now, foo resolves to a global var #'foo, which is created when the (def ...) form is analyzed. In the second case, it resolves directly to the function object. Thus, it should save us a var dereference at runtime in this case.

EDIT: Found out, this is exactly what direct linking is used for.

Evaluating forms using eval can create a valid undesirable recursion point

Mon, 16 Mar 2026 23:17:54 +0000

When the eval function in Clojure is called with an argument that is an instance of IPersistentCollection which likely isn't a special def-like form (the first element isn't a symbol at all or it does not start with "def"), the form is first wrapped in an anonymous function which then gets compiled and invoked, which indirectly evaluates the original form.

There aren't any extra checks performed and it makes forms like these 2 valid, which should normally be rejected and a compiler exception should be thrown:

(recur)

(let []
  (print "Hello")
  (Thread/sleep 1000)
  (recur))

where the 2nd form keeps printing "Hello" and loops infinitely over the outer wrapper function.

bit-count in cljs but not clj

Fri, 30 Jan 2026 09:21:40 +0000

The bit-count function ships as part of CLJS but not CLJ, which means I end up using a reader conditional to use Long/bitCount on the JVM side when I write cljc files. It would be nice if I could just use bit-count.

(I chose "compiler" for category because there's no option for "standard library")

How to force clojure.spec generator to skip a field

Thu, 15 Jan 2026 07:58:46 +0000

(gen/let [x (s/gen (s/keys :opt [::a]))
          y (s/gen (s/keys :opt [::a]) {::a ???})])

If x generates without ::a, I'd also like to generate y without ::a. I can't presently see a way to express that.

clojure.core/subs should use type hints of ^CharSequence, NOT ^String

Tue, 13 Jan 2026 18:10:48 +0000

This is related to this ancient ask, but it would be ideal if clojure.core/subs was type hinted with ^CharSequence rather than ^String, and used the subSequence() method instead of substring() (since the latter doesn't exist in CharSequence).

The single parameter version of subs would need to call s.length() as the second argument in the call to subSequence() (there is no single-arg version of that method, unlike substring()).

More generally, there are substantial benefits in using CharSequence instead of String throughout Clojure core, not only in the context of Java interop, but also when using custom String-like data structures (e.g. ropes).

[edit] @alexmiller mentioned this in another forum (and I'm capturing it here for posterity), but this might also require that the result be stred, to ensure the return type remains unchanged (subSequence() returns a CharSequence, unlike substring, which might break callers). There may be performance implications of adding that call for types other than String (but existing callers should be unaffected, since String.toString() is identity).

Literals for Unicode code points (and perhaps also sequences thereof)

Mon, 12 Jan 2026 20:02:41 +0000

Context
For historical reasons the JVM type system's support for Unicode code points is poor, and while this is usually invisible to the developer it becomes a hassle when String literals containing non-Latin1 code points are used in code. It also becomes particularly problematic when cross-platform (cljc) code is attempting to do this, since other platforms may not share this historical oddity so solutions that "work" in ClojureJVM may break in other dialects.

For example, the transgender flag emoji (a single grapheme cluster that happens to be defined by 5 Unicode code points) cannot easily be constructed at the REPL or in a source file without detailed knowledge of the JVM's history (and associated knowledge of UTF-16, an increasingly obsolete character encoding).

Using the documented code points for this grapheme cluster with the JVM's Unicode escaping mechanism does not give the expected outcome:

The correct, but unintuitive solution is to remember that the JVM does not directly support Unicode code points in the supplemental planes, and then to translate the supplemental code point U+1F3F3 into its UTF-16 code unit / surrogate pair representation:

Note: I had to use screenshots for this, since ask.clojure doesn't appear to support Unicode supplemental code points properly either...

Question/request/proposal
Clojure can sidestep this issue in a purely accretive manner, providing better consistency across the JVM and other runtimes, by adding direct support for Unicode literals.

This would involve adding a new literal syntax that represents a single Unicode code point, and perhaps also a new literal syntax that represents a sequence of Unicode code points (perhaps supporting not only the novel Unicode code point literal, but also the existing Character and String literals). Both of these new literals would produce a standard JVM (or JavaScript, or ...) String object, in whatever native encoding those objects employ on their respective platforms - after such literals are read, it's all just the extant String data type - there is no runtime impact.

An example literal syntax

While I am not proposing a specific syntax for these new literals here (though such a task is a necessary step), for illustrative purposes here is an example of what these literals might approximately look like:

Single Unicode code point literals:

#U+0061: produces a String containing the Latin letter a: "a"
#U+1F921: produces a String containing the clown emoji (which ask.clojure cannot display)

Sequences of Unicode code point literals:

#U+[U+0061 U+0020 U+1F921]: produces the 3 grapheme cluster String: "a <clown emoji>"
#U+["a " U+1F921]: produces the same String, but demonstrates why it may be useful to support a mix of literals within the sequence (for readability)
#U+[\a \space U+1F921]: ditto
#U+[U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F]: produces a String containing a single grapheme cluster (the transgender flag emoji)

This final example is an ideal test case, since the transgender flag emoji is a single Unicode grapheme cluster, defined by 5 Unicode code points, but on the JVM (for the historical reason listed originally) is made up of 6 Characters.

Note that the sequence literal may not be necessary, since str could be used with the single code point literal syntax; e.g. (str #U+1F3F3 #U+FE0F #U+200D #U+26A7 #U+FE0F). Whether shifting the cost of string concatenation from read-time to runtime matters or not is another topic worthy of deeper consideration.

Other notes
Orthogonal to this proposal (at least from a Clojure core perspective; from a user perspective they're closely related), it would also be useful if Clojure core (perhaps in the clojure.string namespace) had functions to turn Strings into sequences of code points (as integers) and vice versa. Both the JVM and JavaScript provide native APIs for doing this (and presumably other platforms do too), but providing these as standard functions in Clojure core (similar to what was done with parse-long, parse-double, and parse-boolean in Clojure v1.11) has value and is also purely accretive.

Why does the REPL incorrectly display my command after I press enter?

Mon, 22 Dec 2025 15:01:06 +0000

Hello,

I'm having a small bug with the Clojure REPL - when I enter a command, after pressing the enter key, the command gets displayed incorrectly - basically the beginning of the text of the command that I entered is displayed for the first few characters, and then everything after that is overwritten with the same text of the command displayed with an indentation.

Not sure if that's very clear, so I've added a pair of screenshots, "before and after", to illustrate.

This issue seems similar to this older question, although in that case the issue was with the rlwrap library, which was patched afterwards.

Is there a way to fix this?

Octal escape sequence decoding in strings does not stop at non-octal digit

Thu, 18 Dec 2025 09:35:53 +0000

Strings suppose to support standard Java escape sequences, including octal escape sequence: [0-7]{1,3}

In Java decoding of octal sequences stop at the first non-octal digit or any other character if there are 1 or two octal digits in the escape sequence. For example:

jshell> "\18"
$1 ==> "\0018"

But Clojure reads up to 3 potentially octal digits greedily resulting in wrongly consuming non-octal digits:

Clojure 1.12.4
user=> "\18"
Syntax error reading source at (REPL:1:5).
Invalid digit: 8

non-octal characters:

Clojure 1.12.4
user=> "\1d"
Syntax error reading source at (REPL:1:5).
Invalid digit: d

And succeed only when there is line terminator or exact three octal digits in supported octal range:

Clojure 1.12.4
user=> "\1"
""
user=> "\1"
""
user=> "\12"
"\n"
user=> "\123"
"S"
user=> "\123d"
"Sd"

[clojure.edn] Leading zeros in numbers

Thu, 04 Dec 2025 13:31:23 +0000

clojure.edn allow leading zeros ending up reading such number as octal representation. The problem is that it is also allowed to have indefinite amount of leading zeros for octals:

000000000000042  ;; => 34

and when there is a suffix "M" that forces floating point representation the same string become float 42 stripping all leading zeros.

000000000000042M ;; => 42M

At the same time EDN specification forbids integers with leading zeros at all even for floats.
I found a ticket about leading zeros in data.json but I think it should be expanded to cover clojure as well.

In the same scope but origin is in the EDN spec:
float specification allows leading zeroes in exponent and only zeros in fractional parts:

0.00000000...00
0.0e0001

probably because of that clojure.edn read such numbers without error too.

Double colon ("::") in the middle or at the end of identifier.

Thu, 27 Nov 2025 12:15:33 +0000

Right now double colon is allowed only when used as a start of not empty identifier prefix. I wonder is there some explanation why it is forbidden anywhere else?

I found original commit, where this was introduced.
https://github.com/clojure/clojure/commit/005ea1b5f96c5bb762e155032a865e29ad71bcf3

But commit message has no explanation why it allows only non-repeating colon

Macro expansion lose type hints

Mon, 03 Nov 2025 13:50:41 +0000

The following snippet demonstrate how type hints when put before a macro expression are being lost.
On the first expression, the compiler correctly complains about the wrong type hint while it gets accepted if you wrap the hinted expression on a macro.

$ clj 
Clojure 1.12.3

user=> (import 'java.util.Date)

user=> (.setHours (Date.) ^long (.getHours (Date.)))
Syntax error (UnsupportedOperationException) compiling fn* at (REPL:1:1).
Cannot coerce int to long, use a cast instead

user=> (.setHours (Date.) ^long (-> (.getHours (Date.))))
nil

`pipeline-blocking` uses `thread` internally instead of `io-thread`

Wed, 29 Oct 2025 15:54:00 +0000

pipeline-blocking is explicitly meant for blocking operations (implying I/O). However, internally it uses thread rather than io-thread for processing: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L637-L640.

Since 1.9.829-alpha2 this has practical implications, as only io-thread will utilize virtual threads, when available.

Can this be fixed / changed?
If not, can an explicit pipeline-io (or similar) function be added to support this use case?

Thanks

clojure -X hangs with agent use

Wed, 10 Sep 2025 21:02:32 +0000

Given this repro:

(ns repro)

(defn exec-fn [_]
  (let [a (agent nil)]
    (prn (-> (java.lang.ProcessHandle/current) (.pid)))
    (send a (fn [_] 3))))

the clojure -X repro/exec-fn invocation is hanging.

This seems to be unintentional, given that clojure -X doesn't wait for futures to finish either?

Can you help me choosing a book?

Tue, 26 Aug 2025 14:58:42 +0000

Greetings,
so I decided to learn Clojure, my background is Erlang. I am not working anymore in the IT industry.

I want to learn Clojure for fun, in my spare time, and I love to use books for that.
I love to build small projects while learning, not just theory.
I see there are trillions of books, and I know it is a very subjective matter.

I am looking for one good for beginners, and with a practical approach.
Can you recommend one?

I love "Clojure for the Brave and True"'s title and cover, and it also seems to build a project.

Is that book still good in 2025?

Cheers!

select-keys on nil map

Fri, 01 Aug 2025 14:42:56 +0000

I know that https://ask.clojure.org/index.php/1913/use-transients-with-select-keys-if-possible exists to optimize select-keys for many keys, but I noticed that it does a lot of work even if the original map is nil. Would there be interest in a patch that returns an empty map when given nil? Something like:

(defn select-keys*
  "Returns a map containing only those entries in map whose key is in keys"
  {:added "1.0"
   :static true}
  [map keyseq]
  (if map
    (loop [ret {} keys (seq keyseq)]
      (if keys
        (let [entry (. clojure.lang.RT (find map (first keys)))]
          (recur
           (if entry
             (conj ret entry)
             ret)
           (next keys)))
        (with-meta ret (meta map))))
    {}))

Compiler-generated `foo__init.class` files lack `SourceFile` attribute

Thu, 31 Jul 2025 22:21:18 +0000

Most .class files generated by Clojure contain the expected SourceFile attribute (you can verify with javap -v). But __init classfiles lack this metadata. I asked @alexmiller on Slack, and he suggested I bring it up here.

The same appears to be true of classes generated via proxy.

Skip stacktrace creation in ExceptionInfo

Thu, 17 Jul 2025 14:46:52 +0000

Many libraries and applications use exceptions as control flow or data collection, which allows for handling complex situations with more consistent and legible code. Some libraries use custom throwables (IGJoshua/farolero, NoahTheDuke/lazytest) and some use ExceptionInfos (scgilardi/slingshot, fmnoise/flow, pangloss/pure-conditioning, exoscale/ex).

One of the reasons that libraries reach for custom throwables is because they want to skip creation of a stack trace (which isn't used and would be thrown away immediately). Stack traces in Java are already fairly expensive to create, and then the filtering work done in ExceptionInfo greatly increases that expense, making them much slower than needed. (There's an Ask about this but I can't find it.) This performance cost pressures developers to use custom throwables if their code will ever be used in a "hot path", which harms portability and ease of development. (I want to write Clojure, not Java, and I want it to be usable in Clojurescript and Babashka and whatever other dialects might arise.)

I know that there's a rejected Jira ticket (CLJ-2423) for supporting the "enableSuppression" flag, but in light of these use-cases, I'd like to bring it up again.

POSIX-style command line arguments in tools (-T)

Thu, 03 Jul 2025 21:06:46 +0000

I have a couple command line tools written as libraries that I'd like to expose as proper Clojure Tools. They have classic POSIX-style command line interfaces, relying on tools.cli. I could add an -X kv-map interface, but there are a number of boolean flags that would not translate well to :foo true style (such as arbitrary file paths).

Is there a way to pass arbitrary arguments to a clojure Tool without using the kv-map style?

And if not, would there be interest in a flag or option that would allow for such a thing?

Why does a qualified instance method call fails at compile time with NullPointerException if missing target

Mon, 30 Jun 2025 13:33:36 +0000

Has anyone else noticed a lot of Syntax error (NullPointerException) when using the new Class/.instanceMethod syntax? Specifically whenever I forget the first argument like

(fn [] (String/.length))

gets

#error{:cause "Cannot invoke \"clojure.lang.Compiler$Expr.emit(clojure.lang.Compiler$C, clojure.lang.Compiler$ObjExpr, clojure.asm.commons.GeneratorAdapter)\" because \"this.target\" is null",
       :via [{:type clojure.lang.Compiler$CompilerException,
              :message "Syntax error compiling fn* at (/private/var/folders/cr/wpw7hgnx0jj9m33g28rtbpzc0000gn/T/form-init4871175438924650637.clj:1:1).",
              :data #:clojure.error{:phase :compile-syntax-check,
                                    :line 1,
                                    :column 1,
                                    :source "/private/var/folders/cr/wpw7hgnx0jj9m33g28rtbpzc0000gn/T/form-init4871175438924650637.clj",
                                    :symbol fn*},
              :at [clojure.lang.Compiler analyzeSeq "Compiler.java" 7677]}
             {:type java.lang.NullPointerException,
              :message "Cannot invoke \"clojure.lang.Compiler$Expr.emit(clojure.lang.Compiler$C, clojure.lang.Compiler$ObjExpr, clojure.asm.commons.GeneratorAdapter)\" because \"this.target\" is null",
              :at [clojure.lang.Compiler$InstanceMethodExpr emit "Compiler.java" 2060]}],
       :trace [[clojure.lang.Compiler$InstanceMethodExpr emit "Compiler.java" 2060]
               [clojure.lang.Compiler$BodyExpr emit "Compiler.java" 6723]
               [clojure.lang.Compiler$FnMethod doEmit "Compiler.java" 6243]
               [clojure.lang.Compiler$FnMethod emit "Compiler.java" 6045]
               [clojure.lang.Compiler$FnExpr emitMethods "Compiler.java" 4500]
               [clojure.lang.Compiler$ObjExpr compile "Compiler.java" 5136]
               [clojure.lang.Compiler$FnExpr parse "Compiler.java" 4662]
               [clojure.lang.Compiler analyzeSeq "Compiler.java" 7667]
               [clojure.lang.Compiler analyze "Compiler.java" 7360]
               [clojure.lang.Compiler analyze "Compiler.java" 7316]
               [clojure.lang.Compiler$BodyExpr$Parser parse "Compiler.java" 6683]
               [clojure.lang.Compiler$FnMethod parse "Compiler.java" 6022]
               [clojure.lang.Compiler$FnExpr parse "Compiler.java" 4585]
               [clojure.lang.Compiler analyzeSeq "Compiler.java" 7667]
               [clojure.lang.Compiler analyze "Compiler.java" 7360]
               [clojure.lang.Compiler eval "Compiler.java" 7736]
               [clojure.lang.Compiler eval "Compiler.java" 7694]
               [clojure.core$eval invokeStatic "core.clj" 3232]
               [clojure.core$eval invoke "core.clj" 3228]
               [nrepl.middleware.interruptible_eval$evaluate$fn__966$fn__967 invoke "interruptible_eval.clj" 87]
               [clojure.lang.AFn applyToHelper "AFn.java" 152]
               [clojure.lang.AFn applyTo "AFn.java" 144]
               [clojure.core$apply invokeStatic "core.clj" 667]
               [clojure.core$with_bindings_STAR_ invokeStatic "core.clj" 1990]
               [clojure.core$with_bindings_STAR_ doInvoke "core.clj" 1990]
               [clojure.lang.RestFn invoke "RestFn.java" 428]
               [nrepl.middleware.interruptible_eval$evaluate$fn__966 invoke "interruptible_eval.clj" 87]
               [clojure.main$repl$read_eval_print__9248$fn__9251 invoke "main.clj" 437]
               [clojure.main$repl$read_eval_print__9248 invoke "main.clj" 437]
               [clojure.main$repl$fn__9257 invoke "main.clj" 459]
               [clojure.main$repl invokeStatic "main.clj" 459]
               [clojure.main$repl doInvoke "main.clj" 368]
               [clojure.lang.RestFn invoke "RestFn.java" 1526]
               [nrepl.middleware.interruptible_eval$evaluate invokeStatic "interruptible_eval.clj" 84]
               [nrepl.middleware.interruptible_eval$evaluate invoke "interruptible_eval.clj" 56]
               [nrepl.middleware.interruptible_eval$interruptible_eval$fn__997$fn__1001
                invoke
                "interruptible_eval.clj"
                152]
               [clojure.lang.AFn run "AFn.java" 22]
               [nrepl.middleware.session$session_exec$main_loop__1065$fn__1069 invoke "session.clj" 202]
               [nrepl.middleware.session$session_exec$main_loop__1065 invoke "session.clj" 201]
               [clojure.lang.AFn run "AFn.java" 22]
               [java.lang.Thread run "Thread.java" 1447]]}

Using letfn* for defining corecursive reified implementations

Fri, 27 Jun 2025 10:38:18 +0000

I was finding a way to have co-recursive reified instances, and after looking at the implementation of clojure.lang.Compiler I've found out that this can actually be achieved with letfn*. Consider the following proof-of-concept:

(defmacro thunk [& body]
  `(reify* [clojure.lang.IFn]
      (invoke [this] ~@body)))

(letfn* [g (thunk (+ 1 2 3 (f)))
         f (thunk (+ 1 2 3))]
    (f))

This works, and seems to be faster than other state-based approaches (e.g. using atom to resolve forward declarations).

This said, I recognize that this may not be standard behavior. for instance using (reify* ...) directly in the letfn* bindings will cause the reify* block to be parsed as a MetaExpr which breaks a cast in the implementation of LetFnExpr. For example:

(letfn* [g (reify* [clojure.lang.IFn] (invoke [this] (+ 1 2 3 (f))))
         f (reify* [clojure.lang.IFn] (invoke [this] (+ 1 2 3)))] 
  (f))

But since this would implicitly add metadata to the reify* forms we get this error:

class clojure.lang.Compiler$MetaExpr cannot be cast to class clojure.lang.Compiler$ObjExpr (clojure.lang.Compiler$MetaExpr and clojure.lang.Compiler$ObjExpr are in unnamed module of loader 'app')

The only way I've managed to create a reify* form without metadata is by creating the form in macro, such as the thunk macro defined in the first example.

Is using reify* within letfn* bindings supported? If not, are there any other methods that avoid mutable state that could be employed in similar cases?

Idiomatic way to use java.util.Optional

Mon, 07 Apr 2025 14:16:59 +0000

Is there an easy way to work with java.utils.Optional values in Clojure? I'm currently using 1.12 so I can say things like (Optional/.orElse foo nil) to convert the optional value to a "normal" value (X or nil), but that and other Optional methods are still sources of tension or boilerplate compared idiomatic Clojure constructs (some-> for example).

If such a way doesn't currently exist, can it be considered for addition to Clojure? Maybe opening up deref to work on Optionals as well.

Why is shuffle not nil-safe?

Wed, 26 Mar 2025 14:04:15 +0000

Shuffling an empty collection is fine:

user> (shuffle [])
[]

But shuffling nil results in NPE:

user> (shuffle nil)
Execution error (NullPointerException) at java.util.ArrayList/<init> (ArrayList.java:181).
Cannot invoke "java.util.Collection.toArray()" because "c" is null

Why is it not nil-safe like other seq ops?

Can we add metaphors/analogies for functional closures in Clojure to the docs please?

Thu, 20 Mar 2025 14:13:58 +0000

Hi,
Having been a longtime happy and satisfied user of Clojure I realized that there is very little to introduce someone new to Clojure to closures where functions [like vehicles] are passed in with opaqueness to their variables [like passengers] to another function. I think this is probably a stumbling block for many beginners and might even, unfortunately, discourage people from adopting the language without further explanation of this caveat. I think many programmers will also disagree with my assessment because they have "closure eyes" and can transparently understand passing functions around as first-class-citizens so-to-speak.

I propose that we amend the documentation to explicitly mention that closures are basically like vehicles or cars with passengers.

the fact that not everything is transparent to the top level function call is something non-obvious

(defn make-adder [x]
 (fn [y] (+ x y)))

(def add5 (make-adder 5))
 (add5 10) ;; Returns 15

In this example:

make-adder is like a vehicle factory. When you call it with 5, it creates a new vehicle.
This new vehicle (the returned function) has a permanent passenger: the value 5 is sitting in the x seat.

There's one empty seat (y) that you can fill when you drive the vehicle (call the function).

When you call (add5 10), you're putting 10 in the y seat and driving the vehicle.

Inside, the passengers interact: x (which is 5) and y (which is 10) are added together.

How REPLs and Closures Intertwine
The REPL (Read-Eval-Print-Loop) and closures interact in interesting ways:

Creation and Persistence:
When you define (def add5 (make-adder 5)) in the REPL, you're parking a vehicle (with 5 already inside) in your garage with the name "add5". This vehicle persists between REPL evaluations.
Inspection Limitations:
In the REPL, you can see that add5 is a function, but you can't directly inspect who's sitting inside it. If you evaluate add5, you'll just see something like #function[user/make-adder/fn--123].
Usage in REPL:
You can use the closure by calling it: (add5 10). The REPL will evaluate this by driving the vehicle with 10 in the y seat, and print the result (15).

core.async 1.8 beta1 cached thread pools can grow to hundreds of threads when doing io work

Wed, 26 Feb 2025 18:54:58 +0000

Hi, I've been testing the new clojure.core.async 1.8.711-beta1, and suspected that since the default fixed thread pool was replaced with a cached thread pool, it could be possible for the system to create a very large number of OS threads, in the order of hundreds or thousands depending on the size of the workload.

I am wondering if this was intended or if there might be a better middle-ground such as still using a CachedThreadPool but potentially accepting maximum sizes for each pool type via sys props, with reasonable defaults.

Example code below:

(ns user)

(require '[clojure.core.async :as a]
         '[clojure.core.async.impl.dispatch :as d])

(defn do-work
  "Simulate some async work which "
  [task-count task-timeout]
  (a/go-loop [c (a/merge
                 (doall
                  (for [i (range task-count)]
                    (a/go
                      ;;; this simulates non-blocking park insdie the go-block
                      (a/<! (a/timeout
                             (rand-int task-timeout)))
                      ;;; this simulates blocking IO inside an io-thread
                      (a/<! (a/io-thread
                             (Thread/sleep
                              ^int (rand-int task-timeout))))
                      i))))]
    (let [v (a/<! c)]
      (if (nil? v)
        {:pool-size (.getPoolSize ^java.util.concurrent.ThreadPoolExecutor (d/executor-for :core-async-dispatch))}
        (recur c)))))

(def active
  (atom false))

(defn run-sim
  []
  (reset! active true)
  (a/go-loop [iter 1]
    (let [start (System/currentTimeMillis)
          {:keys [pool-size]} (a/<! (do-work
                                     2000  ;;; simulated number of tasks
                                     100)) ;;; simulated max delay in ms
          stop (System/currentTimeMillis)
          elapsed (- stop start)]
      (println "Iteration:" iter "Pool Size:" pool-size "Elapsed:" elapsed)
      (when (and @active
                 (< iter 10))
        (recur (inc iter))))))

(defn stop-sim
  []
  (reset! active false))

(comment
  (run-sim)   ;;; run the sim
  (stop-sim)) ;;; stop the sim

a) how: programmatically set REPL ‘context’ ‘prj-1 aware’? b) how: programmatically switch REPL ‘context’ ‘prj-n aware’?

Sun, 23 Feb 2025 16:56:50 +0000

Ok, regardless of editor, running clj in a directory will start a repl that has "project context" to project deps.edn in that directory, and that is the way that most Clojure developers create a connected repl.

The implication seems to be to work on a different project one must (System/exit 0) VM and start another VM using clj command to ‘create a connected repl’ to project deps.edn in a different directory? This appears to be idiomatically (colloquially) referred to as ‘restarting the REPL’ I believe?

Seems rather draconian for a dev env, let alone a lisp dev env? I thought the highly dynamic heritage of lisp replete with multiple REPLs was universally sought after? 10 years later and no multiple REPLs for clojure? Personally, I’m somewhat surprised, but maybe nobody really wants, needs or requires multiple clojure REPLs? I think multiple REPLs could be transformational in many use cases IMHO, or maybe I’m really ‘out of the loop’ no pun intended?

03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/mgwvmEnjnBoJ) several notable sub-quotes:

“I think it is important, with tooling, to have the broadest, open notion of the types of 'use cases' for Clojure, and for workflows of people using Clojure, lest you actually limit them. I hope people are able to write their languages and DSLs, test embedded control/debug consoles, design next-generation REPLs and debuggers, grab data dumps etc, all from their REPL. That's the heritage of Lisp. Many people are doing data science, languages, genetics, rule-systems etc type things with Clojure, not just web apps

But it is quite common in rich Common Lisp IDEs like Lispworks for people to have multiple listener (REPL) sessions open at the same time (against the same runtime). You can launch long running processes that produce streaming output, switch to another listener and continue interaction and development, have separate listeners for separate contexts/state/command-history etc. There's a lot to Lisp development that's not RPC.

Note multiple listeners, data inspectors and more. Maybe not the latest GUIs, but the capabilities should be a source of inspiration for any Clojure IDE.”

Previously hinted personal end goal: exploit ‘critical mass’ for a (truly) ‘dynamic’ clojure dev env, including dynamic java recompilation, namespace reloading, etc. and include at a minimum:

clojure.repl.deps
clojure.tools.build.api (clojure.tools.build)
clojure.tools.deps
clojure.tools.deps.cli.api (clojure.deps.cli)
clojure.tools.namespace
clojure.tools.tools.api (clojure.tools.tools)
GitHub - clj-commons/virgil: Recompile Java code without restarting
the REPL (https://github.com/clj-commons/virgil)
other polyglot ‘evaluation/compilation’ TBD

I also included a few tools to help come back up to speed quicker:

GitHub - nubank/morse: A graphical, interactive tool for browsing
Clojure data (https://github.com/nubank/morse)
[clj-ns-browser/clj-ns-browser "2.0.0-SNAPSHOT"] – Clojars
(https://clojars.org/clj-ns-browser/versions/2.0.0-SNAPSHOT)

Eventually will look at many ‘current projects’ including: GitHub - HumbleUI/HumbleUI: Clojure Desktop UI framework (https://github.com/HumbleUI/HumbleUI) as stated to build better apps than possible with web, AND access full power of your computer (multithreaded), wouldn’t that be convenient?

Another quote from 03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/IHoVWiJz5UIJ):

“REPL stands for something - Read, Eval, Print, Loop. It does not stand for - Eval RPC Server/Window.”

Anyway, that would be ERSW, seriously, I couldn’t agree more, a required lisp feature, for me anyway: multiple simultaneous-concurrent (multi-threaded) REPLs, I refer to as ‘Clojure Listeners’ (‘in-process’ or ‘against the same runtime’) non-socket non-nREPL non-LSP non-network non-middleware non-multi-VM based REPL approaches that support multiple simultaneous dev management ‘native VM’ approaches for polyglot projects ala GraalVM.

[SEE Multiple Clojure Listeners] (https://github.com/mgrisius/clj-mode/blob/0.9/Clojure_Listener_2025-02-23_09-02-41.jpg)

Note JavaScript Listener “JS-1” pictured. Could have python, R, ruby, or whatever language(s) available in GraalVM. ‘Clojure Listeners’ used with or without emacs, ‘regardless of editor’, in any Java VM for that matter. Could easily have multi-threaded socket-based listeners . . .

Clojure Listeners: multi-threaded, full history, type ahead, line editing, completion, pop-up menus, colorized output, colorized-balanced-brackets-([{, etc. Also working on other listener features: multi-line editing, enhanced source lookup, doc lookup, repo-artifact search, embeddable .e.g. in morse, etc. all leveraging the ‘purest clojure value chain possible’!

As previously mentioned, my basic ‘old style’ simple.bat with (~60mb) über jar simple compatibility with emacs lisp-inferior-mode works good with ‘legacy’ approach and new ‘CLI deps.edn approach’ basic use so far, both with ~1 second startup time. Zero optimization has been done thus far, e.g. GraalVM native image, etc.

My forward-looking goal & reason for asking initial question: compatibility with future clojure tool direction(s), NOT invent the next ‘technical debt’ ad hoc one-off hack. My Holy Graal: I want a fully dynamic long running VM under full clojure programmatic control.

So, the question remains: a) how to programmatically set REPL with ‘context’ for ‘project-1 aware’? b) how to programmatically switch REPL ‘context’ to ‘project-n aware’?

Comparing ratios with BigDecimals can throw

Fri, 21 Feb 2025 20:52:49 +0000

Observe:

(< 1/4 0.5M)
;=> true        ; as expected

(< 1/3 0.5M)
; Execution error (ArithmeticException) at java.math.BigDecimal/divide (BigDecimal.java:1783).
; Non-terminating decimal expansion; no exact representable decimal result.

This is because Clojure tries to coerce the ratio to a BigDecimal, which can fail.

This worked (and produced expected results) in Clojure up to 1.2.1; the current behaviour is from 1.3.0 onwards. Not sure whether this is a bug or expected behaviour; in either case, I haven’t seen it documented.

>, <=, >= all exhibit the same behaviour. = works.

I’ve also noticed that = can’t determine whether a ratio is equal to a bigdec, although < and > do sometimes produce a good answer:

((juxt < = >) 1/2 0.5M)
;=> [false false false]

((juxt < = >) 1/4 0.5M)
;=> [true false false]

The same is true of ratios and doubles:

((juxt < = >) 1/2 0.5M)
;=> [false false false]

((juxt < = >) 1/4 0.5M)
;=> [true false false]

This seems contrary to the docstring of =, which states that „[it] compares numbers and collections in a type-independent manner”.

a) how to start REPL with ‘context’ for ‘project-1 aware’? b) How to switch REPL ‘context’ to ‘project-n aware’?

Mon, 17 Feb 2025 17:14:46 +0000

Been away from clojure for a while, taking a fresh look at CLI & deps tool chain current status, direction & potential work flow(s). Previously maintained linux, macOS & MS Win / WSL2 dev envs, only looking at MS Win clojure right now.

Dev env includes GraalVM JDK 23, clojure 1.12.0, emacs 27.1 with minimal (ancient) lisp-inferior-mode clj-mode (https://github.com/mgrisius/clj-mode), and Apache ant/ivy 1.10.3 for Transitive Dependency Management (TDM), classpath & java command construction. My ‘legacy’ emacs, clojure & java code are operational again.

Using basic ‘old style’ simple.bat with (~60mb) über jar simple compatibility with emacs lisp-inferior-mode with ~1 second startup time, e.g. m-x eval-expression (run-lisp “simple.bat”):
java -cp E:\dev\projects\simple\target\0.0.1.standalone.jar clojure.main

Current goals include: convert to CLI & deps tools, among others.

Installed clj-msi (Clojure 1.12.0.1501) Clojure for Windows 25.5.3460.1501, create basic project, deps.edn etc. Can use CLI from cmd.exe or powershell.exe to execute basic actions: invoke REPL, check versions, download deps, create über jar etc. Command line stuff works good!

Not sure how best to leverage CLI & deps from a basic .bat file so that the resulting REPL is ‘project aware’, e.g. sees project deps.edn, build.clj, user.clj plus ‘tools.build’ related capabilities? So far, subtle differences between CLI interactive and basic .bat cmd.exe or powershell.exe results.

As the tools.build Guide states: “We want to write this program with our favorite programming language, Clojure, and tools.build is a library of functions commonly needed for builds that can be connected together in flexible ways. Writing a build program does take a bit more code than other declarative approaches, but can be easily extended or customized far into the future, creating a build that grows with your project.”

I prefer writing clojure code over complex cross platform compatible (shell) scripts, workarounds or hacks. So, I think I want full CLI functionality to use from the REPL to avoid incidental complexity, e.g. ‘very complicated’ problems discussed in Clojure CLI Reference in ‘Quoting keys and values’ related to platform specific issues wrt cmd.exe or powershell.exe concerns. Overall goal: avoid ‘technical debt’ from ANY platform specific minutiae for ANY shell, e.g. bash/tcsh, cmd.exe, powershell.exe, or even any new emacs lisp to focus solely on investment in purest clojure value chain possible.

BTW: happily seems like there’s ‘critical mass’ for a (fairly complete) ‘dynamic’ clojure dev env with tools akin to early lisp machine (lispm) (e.g. Symbolics) ‘procedural’ style defsystem.

Re-read clojure doc a few times, no mention on how a REPL is or s/b connected (‘in-process’) in a single VM with access to a ‘project’ with ‘tools.build’ and related features enabled? Or how to switch ‘build context’ to another ‘project’. Looked at monorepo / Polylith type subprojects that use ‘with-project-root’. Might be a good fit for a ‘mega project’ but doesn’t seem like a good fit (at least to me) for disparate, scattered or loosely coupled projects. Could keep a list of target project dirs and ‘map’ specific build tool process using ‘with-project-root’?

Also mentioned in tools.build Guide: ‘Parametrized builds’ that s/b easy to use from CLI and via programmatic use to generate :dev :test :debug :deploy :install :prod :maintenance or :whatever actions or artifacts are required in conjunction with a ‘clj -T:build action-name’ approach. Seems very reasonable, if there was a repeatable initial setup or process to make project deps.edn etc. & tools.build aware at a REPL.

To summarize, it would be nice to have a minimal .bat file and/or ‘user.clj’ to enable the CLI deps experience/capabilities/tools programmatically via REPL. Am I over thinking or missing anything here? Perhaps by design or maybe it’s too early to ask for normative, idiomatic or canonical recommendations?

My initial question is a) how to start a REPL with ‘context’ that is ‘project-1 aware’? b) How to switch a REPL ‘context’ to be ‘project-n aware’?

I apologize I’m just starting out with CLI, deps.edn, tools.build, user.clj, etc. and have not absorbed many of the intricacies re required libraries, operational details, setup and intended use cases. Any suggestions would be greatly appreciated, thanks for sharing any insights!

What is idiomatic way to represent an immutable pair in Clojure?

Thu, 26 Dec 2024 18:02:36 +0000

Hi!
What is idiomatic way to represent an immutable pair in Clojure where pair is an immutable container for two component (kinda first and last) which can't be modified after construction.

Use case is following -- create data structure with first and second components which will not be modified by consumers. Consumers will read first and second components using destructuring or first/second selectors.

I can see a de-facto way to represent it via vector.
There are other alternatives like:
- use list
- use MapEntry

it seems that list is "ligther" data structure than vector. Maybe using list to model pair for the use above has advantages? (less pressure on memory, etc.)

Thanks!

How to define namespace interface boundaries (like with index.js files in JS)

Thu, 26 Dec 2024 09:26:55 +0000

tl;dr

One of the things I actually like about JS is that I can declaratively define the interfaces/boundaries of folder-level modules through defining a public interface by re-exporting what's supposed to be accessible to other modules and I'm wondering if there's something similar in Clojure (and if not - what's the best way to request a feature).

EDIT: Don't know why the formatting isn't working, the question's preview looks fine...

Let's say there's the following folder structure:

I don't want the catalog and checkout modules to know anything about internal things of the product module. Instead I want the product module (all modules actually) to declare its interface, which to me means that there's a file that explains what's being exposed and supposed to be used.

In JS, I can define whatever is supposed to be publicly by using index.js files that do only one thing: re-exporting what's supposed to be public. Everything else is considered internal (can be enforced with eslint).

This helps tremendously to maintain a loosely coupled and strongly cohesive project. With this, the internal structure of the src/product module can be re-organized in any way, as long as the interface does not change, the rest of the application doesn't need to care.

I've seen many clojure examples like this:

`clj
(ns my-project.catalog.catalog-related-module.get-catalog-page
(:require [my-project.product.product-related-module.foo :as foo]))
`

So I'm wondering if there's a way to add re-exporting files, so I could do this:

`clj
(ns my-project.catalog.catalog-related-module.get-catalog-page
(:require [my-project.product :refer [foo]]))
`

In javascript I could achieve this by using index.js files:

`js
// src/product/product-related-module/index.js
export { foo } from './foo.js'

// src/product/index.js
export { foo } from './product-related-module/index.js'
`

Ideally I could even restrict from requiring anything from a namespace inside the product-namepsace when accessing from outside.

Java interop issue

Tue, 12 Nov 2024 19:25:31 +0000

Hi everyone,

Failing to make clojure work with our commercial java library. I can run the following Java code on my machine and it works fine:

import com.numerix.pro.Application;
import com.numerix.pro.ApplicationCall;
import com.numerix.pro.ApplicationData;
import com.numerix.pro.ApplicationObjectFactory;
import com.numerix.pro.ApplicationWarning;

public final class FxAmericanOption {

    public static void main(final String argv[]) 
    {
        int rVal = 0;      // exit value
        try {
            System.out.println("Running: " + new Throwable().getStackTrace()[0].getClassName() + "\n");

            final Application app = new Application();
            {
                final ApplicationCall call = new ApplicationCall();
                call.addValue("ID",       "USD_Curve");
                call.addValue("OBJECT",   "Curve");
                call.addValue("TYPE",     "Yield");
                call.addValue("Now Date", ApplicationObjectFactory.parseDate("26-Oct-2003"));
                call.addValue("CURRENCY", "USD");
                call.addValue("RATE",     0.04);

                final String[] outHeaders =
                    new String[] {"Updated", "Timer", "ID"};

                final ApplicationWarning warning = new ApplicationWarning();

                app.call(call, outHeaders, warning);

I tried porting it to clojure 1.12 like this

(ns hello
  (:import (com.numerix.pro Application ApplicationCall
                            ApplicationWarning 
                            ApplicationObjectFactory)))
           
(def myapp (new Application))
(def appcall (new ApplicationCall))
(def warning (new ApplicationWarning))

(.addValue ^ApplicationCall appcall "NAME" "Yield Curve")
(.addValue ^ApplicationCall appcall "ID" "MyCurve")
(.addValue ^ApplicationCall appcall "OBJECT" "Curve")
(.addValue ^ApplicationCall appcall "TYPE" "Yield")
(.addValue ^ApplicationCall appcall "Now Date" (ApplicationObjectFactory/parseDate "26-Oct-2023"))
(.addValue ^ApplicationCall appcall "CURRENCY" "USD")
(.addValue ^ApplicationCall appcall "RATE" 0.04)

(def outHeaders (into-array String ["timer" "id"]))

(^[ApplicationCall String/1 ApplicationWarning] Application/.call ^Application myapp
                                                                  ^ApplicationCall appcall
                                                                  ^String/1 outHeaders
                                                                  ^ApplicationWarning warning)

I can inspect appcall object and it looks totally fine - all the .addValue register correctly with it. But when I evaluate the last form with Application/.call I get an error which I don't understand how to address..

 Execution error (IllegalAccessError) at hello/eval10370 (REPL:25).
; failed to access class com.numerix.pro.ApplicationCommon from class hello$eval10370 (com.numerix.pro.ApplicationCommon is in unnamed module of loader 'app'; hello$eval10370 is in unnamed module of loader clojure.lang.DynamicClassLoader @cc01572)

Any help much appreciated!

Found some typos in clojure.core, how to contribute a patch?

Sun, 29 Sep 2024 14:22:30 +0000

Hi,

For example, if is mispelled in defonce docs:

(defmacro defonce
  "defs name to have the root value of the expr iff the named var has no root value,
  else expr is unevaluated"

I've already signed the Clojure Contributor Agreement.

Separate bindable reporting function from clojure.test/report

Tue, 27 Aug 2024 18:38:20 +0000

Set Up

clojure.test is built on the idea that a test will call an assertion function that directly calls a reporting function: is calls report (through do-report). The function report is a multimethod, allowing for adding or overriding keys to allow for implementing alternative reporting styles. It's also dynamic, meant to be rebound if an entirely new reporting system is to be used (TAP, JUnit, etc).

Problem

As discussed in the excellent kaocha source code, these two approaches don't work together, which leads to issues such as kaocha's workarounds (and monkey-patching), leiningen's monkey-patching, Cursive's test runner not always integrating with other tools due to binding report, and others.

Alessandra Sierra wrote about this issue as well when she attempted a follow-up to clojure.test called Lazytest (which I have resurrected over the last year). She ended up not finishing the library, and many other alternatives to Clojure test have not been as successful as one might hope either.

Given that clojure.test is here to stay, it seems prudent to make it easier to use and adapt without changing the fundamental api.

Potential Solution

Separating the "dynamic variable to be rebound" from "the default reporting function" would make it easier for libraries and tools to choose to extend report or replace it entirely, without worrying that they'll clash or run into each other. This can be accomplished by adding a new dynamic variable *reporter* to clojure.test that do-report calls, and defaulting *reporter* to clojure.test/report. (report would stay dynamic so as to not change working code.)

With such a change in place, workarounds such as Leiningen's monkey-patching could simply bind *report* with a new function and not worry about stepping on any other library's toes.

How to suppress/capture the output of defspec for use in clojure.test?

Tue, 06 Aug 2024 20:41:33 +0000

I've been a fan of test.check since the beginning. However, I've never found a convenient way to capture the output when using defspec. When used with clojure.test, one gets output that looks like:

Testing tst.tupelo.y64 {:result true, :num-tests 999, :seed 1722976402694, :time-elapsed-ms 53, :test-var "dospec-line-53"} {:result true, :num-tests 999, :seed 1722976402747, :time-elapsed-ms 36, :test-var "dospec-line-44"}

somewhat polluting the unit test output. How can one capture and/or suppress this output?

Type inference in defn?

Mon, 22 Jul 2024 01:43:33 +0000

(ns graalvm-list-issue.main
  (:require
   [clojure.java.io :as io])
  (:gen-class))

(defn- home-path []
  (System/getProperty "user.home"))

(defn- local-dir []
  (io/file (home-path) ".local"))

(defn -main [& _args]
  (println (seq (.list (io/file (home-path) ".local"))))
  (println (seq (.list (local-dir)))))

(Full code is here: https://github.com/conao3/clojure-graalvm-list-issue)

The first println line has no reflection, the second println line has reflection, and an error occurs during execution in GraalVM.
I see no difference between the two calls, and since it is obvious that it is io/file as the return value of local-dir, it should be type-inferred as java.io.File. What do you think?

Investivate Clojure source code:

Key function is hasJavaClass and getJavaClass.
https://github.com/clojure/clojure/blob/8c8e4f6ef21f3d0f59deb60cdc7e1b584f596d59/src/jvm/clojure/lang/Compiler.java#L359-L361

FnExpr: https://github.com/clojure/clojure/blob/8c8e4f6ef21f3d0f59deb60cdc7e1b584f596d59/src/jvm/clojure/lang/Compiler.java#L4450-L4454

InvokeExpr: https://github.com/clojure/clojure/blob/8c8e4f6ef21f3d0f59deb60cdc7e1b584f596d59/src/jvm/clojure/lang/Compiler.java#L4286-L4290

Ref transactions causing deadlock at the REPL

Tue, 09 Jul 2024 14:28:33 +0000

Hi,

I've come across some strange behavior while playing around with refs at the REPL.
So I have a ref with a simple watcher function:

(defn watcher [_ r o n]
  (printf "ref: %s old: %s new: %s time: %d\n" @r o n (System/currentTimeMillis))
  (flush))

(def x (ref 2))
(add-watch x nil watcher)

I then evaluate the following expression two times in a row:

(future (dosync (ensure x) (Thread/sleep 3000) (alter x * 2)))

What I would expect to happen is that the watcher function should print the ref's value two times in a row, about 3 seconds apart.
But nothing happens.
When I then try to access the ref with another command such as

(dosync (ensure x) (alter x inc))

The REPL blocks completely. Once I did get the expected results several minutes later, another time I got this error message:

Execution error at reftest.core/eval24449 (form-init12758928819079876959.clj:34).                                               
Transaction failed after reaching retry limit

What I find perplexing is that everything seems to work just fine when I evaluate this let-block:

(let [x (ref 2)]
  (add-watch x nil watcher)
  (println "start:" (deref x))
  (future (dosync (ensure x) (Thread/sleep 3000) (alter x * 2)))
  (future (dosync (ensure x) (Thread/sleep 3000) (alter x * 2)))
  (dosync (ensure x) (alter x inc))
  (println "end:" @x))

Is the behavior at the REPL some kind of bug or am I doing something wrong?
How can I make sure that such STM transactions don't fail in real code?

Optimize `select-keys`

Tue, 11 Jun 2024 07:18:28 +0000

Some preliminary testing show that select-keys can be almost twice as fast if it were rewritten to use a transient map rather than a proper map as it does today.

In order to do so, select-keys would need to move to after where transient and its friends are defined.

If there is any interest in pursuing this, I'd be happy to provide a problem statement, more data on the performance, a couple of possible solutions, and perhaps ultimately a patch.

Documentation on alternative radix/0-prefixed numbers

Tue, 30 Apr 2024 16:22:09 +0000

The data structures section on numbers (https://clojure.org/reference/data_structures#Numbers) doesn't mention any of the alternate radix numbers. Reading the code in LispReader is challenging, I'm not exactly sure how it should work. Is there another place this is documented? If not, can the various ways be documented?

Here's what I've discovered from reading the regex and code, not sure which of this is intentional or undefined behavior:

0      ; 0
+0     ; 0
+0N    ; 0N
1      ; 1
-1     ; -1
123    ; 123
123N   ; 123N
0x1A   ; 26
0x1AN  ; 26N
012    ; 10
012N   ; 10N
12r1   ; 1
12r1N  ; fails
12r2a  ; 34
12r2aN ; fails

Cannot invoke "clojure.lang.Var.isBound()" because "clojure.lang.Compiler.LOADER" is null, potential bug?

Thu, 18 Apr 2024 16:11:35 +0000

As per discussion on slack I'm posting here the findings regarding clojure.lang.Compiler.LOADER being null during the analysis phase of GraalVM native-image run.

The full reproduction can be found here and the link to issue on Oracle GraalVM side here.

What is this issue about?

Native Image cannot be produced and throws an error during analysis phase when Clojure 1.11.2 (although the previous version of Clojure might be also affected) is used and reflection entries for java.lang.UUID and clojure.lang.Keyword are present in reflectionconfig.json.

I can't however reproduce the error prior to Clojure 1.9.0. For more information please kindly take a look into a repro.

Why does compilation of fn fail when referencing a class with a failing static field initializer?

Mon, 08 Apr 2024 15:01:01 +0000

Given a Clojure function which references a class, if that class has a static field with an initializer which fails when run, the function will fail to compile because the compiler (needlessly) runs the initializer even if the respective field is not accessed. Notably, this does not happen when storing the class in a var and then referencing it through that instead (see workaround below). Could the compiler support the direct reference here?

Reproducer

(The following code is also available at https://github.com/bevuta/clojure-fn-compilation-issue-repro)

deps.edn:

{:deps {io.netty/netty-codec {:mvn/version "4.1.108.Final"}}}

src/repro/fail.clj:

(ns repro.fail
  (:import io.netty.handler.codec.compression.BrotliOptions))

(defn bar []
  BrotliOptions)

(defn -main [& args]
  (prn (bar)))

Here, the bar function references the io.netty.handler.codec.compression.BrotliOptions class. That class has a package-private static field named DEFAULT with an initializer. That initializer depends on a class which is provided by an optional third-party library. However, even though bar never references that field, the initializer gets run and fails because that library is not present.

Run it like this:

$ clojure -M -m repro.fail
Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass (BuiltinClassLoader.java:641).
com.aayushatharva.brotli4j.encoder.Encoder$Parameters

Workaround

The issue can be worked around by putting the class value into a separate def and using that in the function instead:

src/repro/ok.clj:

(ns repro.ok
  (:import io.netty.handler.codec.compression.BrotliOptions))

(def foo BrotliOptions)

(defn bar []
  foo)

(defn -main [& args]
  (prn (bar)))

Run it like this:

$ clojure -M -m repro.ok
io.netty.handler.codec.compression.BrotliOptions

Relevance

The issue was encountered in the context of https://github.com/clj-commons/aleph/issues/703

Returning the last assigned value from `let` w/o a body

Wed, 13 Mar 2024 23:17:32 +0000

This is more of a suggestion, not really sure where to post it though. Please refer me to the relevant forum if there exists a better one.

Basically I'm going under the assumption that no one uses let without a body. The only reason I can imagine for doing that is purely for side-effects, and do etc. are a much better fit, and currently (let [x 1 y 2 z (+ x y)]) => nil (rather than throwing a spec error, as if this is useful expected behavior? But why?)

In any case, if my assumption is correct, then I propose let returns the last assigned value, such that (let [x 1 y 2 z (+ x y)]) => 3, that is z. This is ergonomic, and intuitive in my eyes. It's also especially useful for long binding forms building off of the same variables only for the final one to be important, which then requires a whole row with special funky indentation just for that.

How to create a short-lived remote-prepl such that it can be gracefully shutdown?

Tue, 27 Feb 2024 17:04:50 +0000

TLDR: How can I start a "one time use" remote-prepl connection that runs a single command, gets the return value, and then releases all resources used?

I asked this in slack but didn't receive a response. It's probably not usually a big deal in practice but it's been bothering me, so I figured I would more formally log it here.

I was under the impression that short lived remote-prepl clients is an intended usage. That it should enable one to connect to the remote, eval something, get the return value and disconnect.

Some example code I found to this effect is here:
https://github.com/Olical/how-to-be-a-repl-sorcerer/blob/b6bd530f3d0c6b165248d980d7ce6cd28e8da51f/src/sorcery/main.clj#L20

Modified slightly:

(ns prepl-question
  (:require [clojure.core.server :as server])
  (:import [java.io PipedReader PipedWriter]))

(def srv
  (server/start-server {:accept 'clojure.core.server/io-prepl
                        :port   0
                        :name   "srv"}))

(defn remote-eval [code]
  (with-open [reader (PipedReader.)
              writer (PipedWriter.)]
    (.connect reader writer)
    (let [result! (promise)]
      (future
        (server/remote-prepl
          "localhost" (.getLocalPort srv)
          reader
          (fn [msg]
            (deliver result! msg)))
        (println "DONE"))
      (.write writer code)
      (.flush writer)
      @result!

      ;; doesn't print "DONE"
      (let [r @result!]
        (.close reader)
        (.close writer)

        ;;(.write writer ":repl/quit\n") ;; also tried this
        ;;(.flush writer)

        r))))

(remote-eval "(+ 1 2 3)")

I've found no way to get "DONE" to print, signifying the stopping of the prepl thread loop, with any combination of closing the streams used.

Looking at the remote-prepl source code a bit, it seems like this line here will call close on the reader, but it will be called when the reader is already closed. But at least in the example above, I've found that this causes things to hang forever when close is called the second time. I'm guessing this is related to the issue described here: https://stackoverflow.com/a/45703662, related to the PipedReader/Writer setup.

But I'm not sure if this could be considered a bug in the prepl code or if I'm using it wrong.

Can direct-linking be enabled for my own code and not for libraries?

Tue, 27 Feb 2024 12:47:39 +0000

Blanketly enablind direct-linking can break libraries, and I can't control what vars in them are affected, but I'd still like to improve performance at least in parts of my own code.

Would the following work?

(binding [clojure.core/*compiler-options* 
  {:direct-linking true}]
  ,,,
  )

Here's the docs: https://clojuredocs.org/clojure.core/*compiler-options*

Why can't I type hint these floats?

Thu, 15 Feb 2024 18:48:26 +0000

I want to ensure I'm using unboxed and unreflected arithmetic on arrays of floats, but I can't get it to compile.

How can I type hint a float in a function like this?

`
(defn ff2a

^"[F" ; Return type hint for a float array

[^float f1 ^float f2] ; Argument type hints

(float-array [f1 f2]))
`

I get this error when I try to load it into the REPL:

Syntax error (IllegalArgumentException) compiling fn* [...] Only long and double primitives are supported

What's an ideomatic way to manage state in a library?

Thu, 15 Feb 2024 12:46:36 +0000

I’m porting a JS library to clojure (and, potentially cljs), and I’m struggling with reasoning about local state. Imagine a scenario where you do RPC over websockets, and the server reply contextually depend on what the server had already sent you. You'd want to keep a local cache of the replies from the server, then.

In OOP world it's expected you incapsulate both the socket and the cache and provide the library users an interface that sends RPCs and transparently handles the cache population and pulling results from it. What would be the ideomatic way to do the same in clojure[-script]? Would I just return a map and expect my functions to take it as a first argument, returning the update state along with the rpc result?

Method values vs Method references

Wed, 14 Feb 2024 10:10:10 +0000

with java method references the following works (this code is taken from java.time.LocalDate):

public static LocalDate parse(CharSequence text, DateTimeFormatter formatter) {
    return formatter.parse(text, LocalDate::from);
}

the second arg to the parse method is a TemporalQuery - a functional interface that takes a single TemporalAccessor as arg. In this example, instead of passing a TemporalQuery instance, here a method reference is being passed, where the method signature matches that of TemporalQuery - ie takes a single TemporalAccessor as arg.

Trying to do similar in clojure:

(^[CharSequence TemporalQuery] DateTimeFormatter/parse formatter "20200202" java.time.LocalDate/from)

results in

Execution error (ClassCastException) at user/eval2266 (form-init14137309762912529150.clj:1).

class user$eval2266$invokeLocalDate_from2268 cannot be cast to class java.time.temporal.TemporalQuery (user$eval2266$invokeLocalDate_from2268 is in unnamed module of loader clojure.lang.DynamicClassLoader @37e99783; java.time.temporal.TemporalQuery is in module java.base of loader 'bootstrap')

Is this a bug or intentional do you think? If intentional, some docs on how clojure method values compare to java method references would be useful.

Method Values and Syntax Errors

Tue, 13 Feb 2024 14:16:48 +0000

Copied from this reddit comment:

So if an ambiguous method is a syntax error (syntax, really?), does that mean that when I update a Java lib that provides a new overload, it will break my code? Even worse, if I have a Clojure lib on the classpath that uses a Java lib, and then update the Java lib and it now provides another overload, the Clojure lib breaks. This would be bad and could result in all kinds of update hell.

Adding an overload is a very common backwards compatible change in Java code that should be expected. Please don't make it create "syntax" errors in Clojure wrappers.

My own words:

One of Clojure's strengths is the resiliency of code, that something written years ago still works today. This has historically applied to libraries that provide idiomatic wrappers around Java libraries as well. However, the use of syntax errors instead of falling back to reflection means that such libraries (if they use the new method values syntax) will be more brittle than other interop code, limiting its usefulness in long-lived code.

I understand the reasons for using hard errors (performance, clarity, simplicity), but I agree that it's a strange choice given Clojure's otherwise incredible flexibility and willingness to support a variety of usages.

What is lost or degraded by falling back to reflection (and a reflection warning) in ambiguous cases?