Clojure Q&A - Search results for https:

Does `:exclude` need to be added to https://clojuredocs.org/clojure.core/require ?

Tue, 13 Feb 2024 19:29:06 +0000

https://clojuredocs.org/clojure.core/require makes no mention of :exclude but this seems to work as it appears:

(require '[clojure.set :refer :all :exclude [join rename]])

Channel for real-time conversation on Freenode irc, visit: https://webchat.freenode.net/

Fri, 04 Aug 2023 14:56:52 +0000

visit: https://webchat.freenode.net/
in channel, type: #clojure
remember that this channel of ours is there for everyone to clear up doubts, talk but above all maintain respect for the next person.
Enjoy it!

Typo in https://clojure.org/guides/tools_build

Sat, 04 Dec 2021 20:04:37 +0000

Hi all
I am afraid there is a typo in https://clojure.org/guides/tools_build

In the Compiled uberjar application build section the build.clj should read

...

(b/uber {:class-dir class-dir

       :uber-file uber-file
       :basis basis
       :main 'my.lib.main}))

currently reads :main my.lib.main (no apostrophe there)

This may be evident for experienced guys but it is a problem for beginners like me

Thanks!

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.

Consider including a built-in wrapper around `java.net.http.HttpClient` in future versions of Clojure

Mon, 08 Jun 2026 01:37:14 +0000

Java 9 introduced java.net.http.HttpClient[1] with support for HTTP/1.1, HTTP/2 as well as WebSocket along with other features. It was later standardized in Java 11[2] and has become one of the top picks for Java programs. The latest version of the HTTP client shipped with Java 26 also added support for HTTP/3.[3]

It would be nice for future versions of Clojure that are based on Java 11+ to include a new namespace with wrapper functions around java.net.http.HttpClient to make it easier (without all the OOP ceremonies) to work with HTTP in Clojure programs out of the box without relying on any 3rd-party libraries.

Examples of prior art:

[1] https://openjdk.org/jeps/110
[2] https://openjdk.org/jeps/321
[3] https://openjdk.org/jeps/517

tools.reader project file version is outdated

Tue, 04 Aug 2026 02:36:36 +0000

Hello! I noticed version currently defined in the tools.reader project.clj file is out of date with respect to the latest git tag. Would it be possible to keep those in sync? This situation is making packaging the library for Debian a bit more complicated than it needs to be. Thanks!

Possibly avoidable identity call to force instance method on Class literals

Thu, 02 Jul 2026 23:47:10 +0000

As of Clojure 1.13.0-alpha2, (.method ClassName) expands to (.method ^Class (identity ClassName)).

This is to force (.method ClassName) to always be an instance method. Without this, it would expand to (. ClassName method), which may instead be interpreted as a static method.

For example, (.getMethods String) expands to (.getMethods ^Class (identity String)).

This was introduced in these two commits:
- force instance member interpretation of (.method ClassName), e.g. (.getMethods String) works
- added autohinting to Class in macroexpansion of (.instanceMethodOfClass Classname) calls

Since then, Clojure has added support for qualified methods which we can use to reliably propagate the tag without any runtime changes. For example, expanding to (Class/.getMethods String) is now equivalent to (.getMethods ^Class (identity String)) in terms of tag propagation.

I have a proof-of-concept here that includes disassembled and decompiled output before and after the change. The net effect of using qualified methods in this case under direct linking is a removal of a single method call to identity:

   3: invokestatic  #20                 // Method clojure/core$identity.invokeStatic:(Ljava/lang/Object;)Ljava/lang/Object;

The effect is more substantial without direct linking (not included in the PR), with clojure.core/identity also being added to the static initializer.

I've also experimented with expanding to (. (do String) getMethods) (see earlier commits in that PR), which seems to also work and might be another approach.

Syntax-quoted lists can return nil, differs from ClojureScript

Sun, 28 Jun 2026 20:43:55 +0000

Syntax quoted lists can return nil if only empty seqables are spliced into it:

Clojure 1.12.5
user=> `(~@[])
nil
user=> `(~@[] ~@[])
nil

However, the implementation then ensures syntax-quoted empty lists are not nil:

Clojure 1.12.5
user=> `()
()

ClojureScript returns an empty list in these cases:

`(~@[])
=> ()
`(~@[] ~@[])
=> ()

The expansion of syntax quote itself is not necessarily a problem if it differs between platforms, but here the evaluation of the expansion differs. This can cause macros to behave differently between platforms (e.g., JVM Clojure vs bootstrapped cljs).

This behavior seems to be present with all versions of Clojure including 1.0.0, so perhaps the ship has sailed here. I went searching for an existing issue or documentation and AFAICT only CLJ-1425 mentions this oddity.

The reference docs for Syntax Quote also seem to contradict this behavior:

For Lists/Vectors/Sets/Maps, syntax-quote establishes a template of the corresponding data structure.

Browser REPL on different port

Wed, 08 Jul 2026 07:16:39 +0000

Clojurescript's built-in browser REPL is on port 9000 by default but that clashes with ZScaler on my work laptop so I use port 8090 instead. It took a few goes to get it working but now I have it sorted.

clojure -M -m cljs.main -v -p 8090 -co '{:closure-defines {"clojure.browser.repl.PORT" 8090}}' -c foo.core -r

There are some points in the documentation that might benefit from clarification. The -p flag is not mentioned on The REPL and main entry points but seems to serve the same purpose as :port described on REPL Options because this also works:

clojure -M -m cljs.main -v -ro '{:port 8090}' -co '{:closure-defines {"clojure.browser.repl.PORT" 8090}}' -c foo.core -r

What is a little bit surprising is that :port is only mentioned under the Node REPL Options section but applies to browser REPLs too.

Not really a question in all this but I wanted to share this for others who might get stuck.

Versions for posterity: Clojure CLI version (deps.clj) 1.12.2.1565 on Windows 11 and ClojureScript 1.11.54.

Weird install paths can break linux-install.sh or posix-install.sh scripts

Mon, 06 Jul 2026 15:46:10 +0000

I'm trying to install clojure from the official installer for once, instead of my old "install lein from apt" method -- I wanted the official tool CLIs.

$ curl -L -O https://github.com/clojure/brew-install/releases/latest/download/linux-install.sh
(completes)
$ chmod u+x linux-install.sh 
$ ./linux-install.sh --prefix "$HOME/.local"
Downloading and expanding tar
clojure-tools-1.12.5.1654.tar.gz: OK
Installing libs into /home/fgabolde@/.local/lib/clojure
Installing clojure and clj into /home/fgabolde@/.local/bin
sed: -e expression #1, char 25: unknown option to `s'

Undeterred, I go back to the docs and find a "POSIX" installer. Aha! That must be it. The other installer assumed something about my shell environment and this one must be written to POSIX specs and that will fix everything!

I download posix-installer.sh, do the same dance, and exactly the same happens.

At this point I remember that when this machine was provisioned, IT made a typo and my homedir is /home/fgabolde@ for no good reason. This has tripped up other programs before. And indeed, the sed invocations in the install script use @ as a delimiter, so my weird homedir terminates the replacement string early.

I fixed it by changing the delimiters in the install script and rerunning.

Add assoc-some for constructing maps while skipping nil values

Fri, 17 Jul 2026 18:23:06 +0000

On latest Clojure alpha, we added :keys! (and :syms!/:strs!) check for key presence. They do not check the value (by design). So a map can have the key, with a nil value, and still pass the check:

(let [{:keys! [a]} {:a nil}]
  a)
;; => nil

Sometimes nil is not a valid value for a given key. In those cases, a programmer may want to avoid adding the key at all, rather than adding it with nil. This is the most common idiom today:

(cond-> m
  (some? v) (assoc k v))

A dedicated assoc-some function would help. It skips the key when the value is nil:

(assoc-some {:a 1} :b 2)
;; => {:a 1 :b 2}

(assoc-some {:a 1} :b false)
;; => {:a 1 :b false}

(assoc-some {:a 1} :b nil :c nil)
;; => {:a 1}

; f returns nil
(assoc-some {:a 1} :b (f))
;; => {:a 1}

Concurrency bug in tools.deps use of Aether/Maven libs?

Tue, 21 Jul 2026 18:08:46 +0000

Occasionally, I've been seeing this error:

[org.eclipse.aether.internal.impl.DefaultTrackingFileManager] [] {} Failed to read tracking file '/home/sean/.m2/repository/org/apache/maven/maven/3.8.8/_remote.repositories' java.nio.channels.ClosedChannelException

which leads to

Expected HashMap$TreeNode, but was given HashMap$Node, at java.util.HashMap$TreeNode/moveRootToFront (HashMap.java:2020) - runtime error (unexpected type).

And the only solution seems to be to blow away part of the ~/.m2/repository and use -Sforce to recompute/redownload.

Any idea what might cause this sort of error? (Windows/WSL2, Ubuntu 20.04, all the very latest CLI/Clojure etc). See Slack thread for more discussion: https://clojurians.slack.com/archives/C6QH853H8/p1784653752175769

More of the stacktrace:
`
at java.base/sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:169)

    at java.base/sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1676)
    at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.fileLock(DefaultTrackingFileManager.java:171)
    at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.read(DefaultTrackingFileManager.java:65)
    at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.readRepos(EnhancedLocalRepositoryManager.java:220)
    at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.checkFind(EnhancedLocalRepositoryManager.java:151)
    at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.find(EnhancedLocalRepositoryManager.java:128)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:360)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:243)
    at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:158)
    at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:204)
    at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1035)
    at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:827)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:336)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:248)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:293)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:183)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:269)
    at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:117)
    at clojure.tools.deps.extensions.maven$read_descriptor.invoke(maven.clj:108)
    at clojure.tools.deps.extensions.maven$eval61086$fn__61087.invoke(maven.clj:148)

Will :keys! work with nested maps?

Mon, 06 Jul 2026 15:20:35 +0000

While learning about the new support for checked :keys!, I came across this test case for nested maps: https://github.com/clojure/clojure/blob/master/test/clojure/test_clojure/data_structures.clj#L1382-L1390.

I have two questions.

First, does this test imply that :keys! will also be supported in nested destructuring?

Second, I think there may be a small issue with one of the test cases. It checks that the following destructuring throws an exception:

{a :a {aa :a :as m :keys! [b c & d e]} :b} (dissoc sample-map :c)

The test passes, but it's not obvious whether that's because :c has been removed from the map or because :e is listed in :keys! without being present. Since the previous test doesn't include :e, it's a bit ambiguous which condition is actually being exercised.

To make the intent clearer, would it make sense to split this into two separate test cases?

One that removes :c and uses :keys! [b c & d], verifying that the missing required key causes the exception.
Another that keeps :c but uses :keys! [b c & d e], verifying that the non-bound but missing :e is what triggers the exception.

Namespaced map conversion fails when namespace keyword starts with a number

Mon, 06 Jul 2026 15:16:32 +0000

It looks like Clojure has no problem with either :0 or :0/a, but when used together in a namesapced map it fails during some internal conversion.

Worst part: it prints back an unreadable form when if I feed it {:0/a :val}

user=> :0
:0
user=> :0/a
:0/a
user=> {:0/a :val}
#:0{:a :val}
user=> #:0{:a :val}
Syntax error reading source at (REPL:45:5).
Namespaced map must specify a valid namespace: 0
:a
:val
Syntax error reading source at (REPL:45:13).
Unmatched delimiter: }

Installing Clojure on IPv6-only machine

Fri, 24 Apr 2026 23:21:53 +0000

Since GitHub (still) do not support IPv6 it is not possible to follow the instructions at https://clojure.org/guides/install_clojure (for Linux, say) to install the Clojure CLI on a machine running ONLY IPv6 (in this case Hertzner).

When downloading the .tar.gz-file manally and uploading it directly, installing the CLI tools is possilbe.

The problems seem to continue installing common clojure dependencies, like data.json 2.5.2, which leads to this:

clj -X:server
Error building classpath. Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:263)
	at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:115)
	at clojure.tools.deps.extensions.maven$fn__1340.invokeStatic(maven.clj:143)
	at clojure.tools.deps.extensions.maven$fn__1340.invoke(maven.clj:143)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at clojure.tools.deps$expand_deps$children_task__959$fn__961$fn__962.invoke(deps.clj:299)
    ...
Caused by: java.net.SocketException: Network is unreachable
at java.base/sun.nio.ch.Net.connect0(Native Method)
at java.base/sun.nio.ch.Net.connect(Net.java:546)
at java.base/sun.nio.ch.Net.connect(Net.java:535)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:585)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.jar

All this seem a bit bisarre of course. Workarounds would make me happy!

Request: allow a user function to be specified as the target of clojure.main/report-error

Tue, 02 Jun 2026 23:53:32 +0000

The three current targets (file, none, stderr) all serialize all of the error data to a string. During development, it would be convenient to be able to define a function that is called with the exception instance. This function might capture additional application state, or open a window in the user's editor, etc.

Note that it is not possible to work around this by replacing report-error itself because the entire clojure.main namespace is AOT-compiled, so alter-var-root has no effect.

See https://github.com/clojure-emacs/cider/issues/3850 for an example where this feature would be helpful.

how to run a clojurescript repl

Fri, 12 Jun 2026 19:52:36 +0000

I've used planck occasionally for years, but now it seems to be deprecated. (Won't build on homebrew.) But it sounds like its functionality has been absorbed by clj. So where can I find documentation about this, and how to run a cljs REPL?

`(nth nil 10)` returns `nil` when it should throw

Wed, 22 Jul 2026 03:30:47 +0000

The doc string for nth reads:

clojure.core/nth
([coll index] [coll index not-found])
Returns the
value at the index. get returns nil if index out of bounds, nth
throws an exception unless not-found is supplied. nth also works
for strings, Java arrays, regex Matchers and Lists, and, in O(n)
time, for sequences.

The behavior agrees when the coll is [] or '() or other empty collections. However:

user=> (nth [] 10) Execution error (IndexOutOfBoundsException) at user/eval280 (REPL:1). null user=> (nth nil 10) nil

Trying to get the 10th item of [] throws but trying to get the 10th item of nil returns nil.

Is taggedliteral's equality check inefficient?

Fri, 27 Mar 2026 13:43:44 +0000

Following on from a very interesting article about tagged literals: https://buttondown.com/tensegritics-curiosities/archive/when-you-run-out-of-types/ I noticed that the implementing class checks for value equality before checking for tag equality.

if (form != null ? !form.equals(that.form) : that.form != null) return false;
if (tag != null ? !tag.equals(that.tag) : that.tag != null) return false;

This leads to the following type of comparison that could be answered immediately but instead takes over a second:

impl=> (time (= (tagged-literal 'foo (seq (range 1e7))) (tagged-literal 'bar (butlast (seq (range 1e7))))))
"Elapsed time: 1911.677375 msecs"
false

it checks if these huge seqs are equal and then compares the associated symbols. Swapping this seems identical semantically but with less computation.

Can clojure builds be reproducible? (new Debian forky requirement)

Tue, 19 May 2026 18:04:14 +0000

Debian now requires packages to be reproducible: https://lists.debian.org/debian-devel-announce/2026/05/msg00001.html and I thought I recalled that compilation, at least, couldn't produce reproducible output (e.g. with respect to variable naming in the class files), and some testing suggests that might still be the case (tested with 1.12.0 via https://diffoscope.org/).

I assume that for Clojure related packages to remain in the next Debian release, we'll need to address the requirement one way or another, if we can, so I wanted to ask about the situation upstream first.

Offhand, I think the main concern is with AOT compilation, which Debian only uses for "leaf" applications, packaged as an uberjar (e.g. leiningen, puppetserver, puppetdb, etc.), and Debian already has infrastructure to make sure that jars are otherwise reproducible (with respect to timestamps, etc.), so the issue there is mostly "just" regarding the file content.

Thanks

Why is aset at least 25 times faster than aset-long?

Mon, 15 Jun 2026 13:19:24 +0000

Working with primitive long arrays, we discovered that aset-long is around 25 times slower than aset, when called statically. Presumably this is because of the inline path for aset. Having a specialised aset-longimplies, to me at least, that the specialised version is going to be faster. I'm inferring that aset-lobg was added for improved performance when invoked through a higher order funciton. Would adding an :inline to aset-long et al be considered? or at least a doc string update to warn about the lower performance?

There is an existing issue for this https://clojure.atlassian.net/browse/CLJ-2840

Is it valid for metadata to have metadata?

Thu, 12 Feb 2026 15:45:20 +0000

Hello,

I am implementing a pretty printer and while adding/testing support for *print-meta* I noticed that pr prints an object whose metadata has metadata in the following way:

user> (binding [*print-meta* true]
        (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork}))))
"^^{:frob :zork} {:bar :baz} foo"

When reading such a form, only the "outermost" metadata is preserved:

user> (binding [*print-meta* true]
        (let [s (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork})))
              o (clojure.edn/read-string s)]
          {:o o
           :meta (meta o)
           :metameta (meta (meta o))}))
{:o foo, :meta {:bar :baz}, :metameta nil}

The behaviour is the same for clojure.core/read-string and also the tools.reader readers.

Can anyone clarify for me if this is either:

simply GIGO
a bug in the printer
a bug in the readers
a state that should be somehow disallowed
something else?

Neither the metadata reference nor the reader reference explicitly allow or disallow such a thing, as far as I can tell. Should they?

N.B. this is not an issue in any kind of production context and I'm not aware of any library or program that constructs such a thing. It's simply something I tested to see if/how it would break the pretty printer I'm building.

EDIT:

I dug into this some more with Nicola. Here's a perhaps much clearer case that demonstrates the reader isn't propagating nested metadata:

user> (let [o ^^:foo {1 2} {3 4}]
        {:o o :meta (meta o) :metameta (meta (meta o))})
{:o {3 4}, :meta {1 2}, :metameta nil}

:metameta should be {:foo true}.

In this section of MetaReader.invoke we are iterating over the entries of the meta map and manually associng them into the existing meta of the object; any metadata on the meta map itself is not preserved. I have a patch that adds a failing test case and correctly propagates the the meta map's metadata. If this is worth a ticket then I'm more than happy to attach it to that or send it to you directly.

requiring an empty .clj without an alias should fail as with an alias

Thu, 02 Apr 2026 18:48:37 +0000

if file a/b/c.clj is "empty"

it creates an empty ns: (and does not fail) when doing

(require '[a.b.c])

while when using ":as" it fails correctly with error:

(require '[a.b.c] :as c)

Syntax error compiling at ... ; namespace 'a.b.c' not
found after loading '/a/b/c'

see here for initial discussion:
https://clojurians.slack.com/archives/C03S1KBA2/p1775155101843229?thread_ts=1775153939.803389&cid=C03S1KBA2

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.

Improving curl options for CLI install scripts (brew-install)

Mon, 26 Jan 2026 12:39:44 +0000

Hi!

I'm the maintainer for Heroku's Clojure buildpack. It uses the install scripts from clojure/brew-install to install the CLI. I noticed intermittent install failures related to the download of the Clojure tools. I believe most of them could be avoided with a slightly changed curl command line options.

I opened a PR before realizing that PRs will not be accepted, so I'm starting this thread to properly get the discussion going. For reference, the closed PR can be found here: https://github.com/clojure/brew-install/pull/10

I believe these options would improve the download behaviour for all users, but especially when used in automations:

--connect-timeout 3 (https://curl.se/docs/manpage.html#--connect-timeout)
Prevents hanging when server is unreachable.

--fail (https://curl.se/docs/manpage.html#-f)
Exit with error code 22 for HTTP responses with status codes >= 400.

--max-time 60 (https://curl.se/docs/manpage.html#-m)
Maximum time in seconds for the entire transfer operation. Prevents hanging indefinitely with slow connections.

--no-progress-meter (https://curl.se/docs/manpage.html#--no-progress-meter)
Introduced in curl 7.67.0 (Nov 2019). Disables the progress bar for cleaner output. But less drastic than --silent and will still output diagnostic information (i.e. retries).

--retry-max-time 60 (https://curl.se/docs/manpage.html#--retry-max-time)
Retry only within this time period (60 seconds). After this time expires, no more retries will be attempted.

--retry 5 (https://curl.se/docs/manpage.html#--retry)
Introduced in curl 7.12.3 (Dec 2004). Retry up to 5 times on transient errors (timeouts, HTTP 408, 429, 500, 502, 503, 504, 522, 524).

--retry-connrefused (https://curl.se/docs/manpage.html#--retry-connrefused)
Introduced in curl 7.52.0 (Dec 2016). Consider connection refused as a transient error for --retry.

These are obviously opinionated and my ask is not for these options specifically. Happy to get anything that will improve the situation. :)

Manuel

gitlibs/tags throws a NPE if the repository has no tags

Fri, 22 May 2026 15:59:50 +0000

Using:

org.clojure/tools.gitlibs     {:mvn/version "2.6.212"}

This throws NPE

(gitlibs/tags "https://github.com/clojure/clojure-site.git")

Additional handling for `&` symbol in map destructuring for :keys/:syms/:strs could be a breaking change.

Thu, 09 Jul 2026 10:01:25 +0000

Before 1.13.0-alpha1:

(let [{:keys [&]} {:& 1}] &)
;; => 1

After:

(let [{:keys [&]} {:& 1}] &)
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: & in this context

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))))

Destructuring {:as opts} unexpected behaviour with seq

Sat, 04 Apr 2026 23:50:39 +0000

Hi,

I found out something weird in some old code, where I wanted to pass the first map in a sequence and by mistake the code was working while actually passing the sequence itself!

After digging to make sense of this, I found out it has to do with the {:as opts} destructuring.

Here's some code:

;; even if something is assigned sequential vs associative
;; the `:as` is transparent
(let [[:as opts] {1 2 3 4}]
  opts)
#_=> {1 2, 3 4}
(let [{:as opts} [1 2 3 4]]
  opts)
#_=> [1 2 3 4]
;; however with a seq it's returned as a map
(let [{:as opts} (seq [1 2 3 4])]
  opts)
#_=> {1 2, 3 4}

;; and it only gets weirder!
(let [{:as opts} (seq [{:k :v}])]
  opts)
#_=> {:k :v}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} {:k3 :v3}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}, :k3 :v3}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} :not-a-map])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Keyword
(let [{:as opts} (seq [1 2 3])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Long

In my case I didn't realize my code was wrong because {:as opts} {:k :v} is the same as {:as opts} (seq [{:k :v}]).

To me this is behaviour I would expect closer to & {:as opts} rather than just plain map destructuring {:as opts}. Maybe both behaviours should be separated?

I think this should be tackled either by
1. make :as transparent regardless of what comes in to always bind
2. throw an error earlier when it's not of the expected destructuring
3. Document this very unexpected edge case in https://clojure.org/reference/special_forms#associative-destructuring
4. Separate the keyword arguments use case from plain map destructuring? (Assuming both are now mixed together)

Support for automatic promotion to BigDecimal in +', *', etc.

Mon, 10 Nov 2025 04:15:47 +0000

Is there support for BigDecimal promotion in the +', *', etc. clojure.core functions?

When I run the following code in the REPL:

(* 2 Double/MAX_VALUE)     ;; ##Inf, Doesn't auto-promote as was expected.
(*' 2 Double/MAX_VALUE)    ;; ##Inf, Expected that it would auto promote.

Following cases also didn't work:

(*' Double/MAX_VALUE 2)        ;; ##Inf, Moving around the arguments.
(*' 2.0 Double/MAX_VALUE)      ;; ##Inf, Using a Double literal instead.
(*' Double/MAX_VALUE 2.0)      ;; ##Inf
(*' Double/MAX_VALUE 2.0M)     ;; ##Inf, Using a BigDecimal literal instead.
(*' 2.0M Double/MAX_VALUE)     ;; ##Inf

I decided to check the Clojure compiler source for promotion, and based on my limited understanding of the code I see that DoubleOps is using the implementation of addP of OpsP abstract class (which just calls the normal add function) while there is one present for LongOps which can be found here.

Is this a bug? And if yes, I would like to work on the fix and I'll check the Development page of Clojure to do the needfull.

TDEPS-269: checksums should use sha256sum instead of shasum

Tue, 27 Jan 2026 11:17:20 +0000

This commit broke our Docker build: https://github.com/clojure/brew-install/commit/d6d540756cb0a6342374db529d07f1de35d5bc71

because shasum is a perl executable provided on Fedora by perl-Digest-SHA-1 rpm, but it's not available on the UBI platform. The standard way to validate checksums is through sha256sum provided by coreutils on most (if not all) linux distributions.

The jira ticket even talks about sha256sum, but then the commit doesn't use it: https://clojure.atlassian.net/jira/software/c/projects/TDEPS/issues?jql=project = TDEPS ORDER BY created DESC&selectedIssue=TDEPS-269

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).

Should reduce-kv support String?

Fri, 29 May 2026 20:42:43 +0000

I like to use reduce-kv on vectors, where the k is the index and the v is the k-th element of the vector. IMHO, it would be convenient if reduce-kv could also work directly on a String. However, IKVReduce isn't implemented for String so that fails. You can use (vec "my-string") as a work-around, but maybe suffer a bit on performance.

I think something like this would work:

(extend-protocol clojure.core.protocols/IKVReduce
java.lang.String
(kv-reduce [^String s f init]
  (let [cnt (.length s)]
    (loop [i 0 res init]
      (if (< i cnt)
        (let [ret (f res i (.charAt s i))]
          (if (reduced? ret)
            @ret
            (recur (unchecked-inc i) ret)))
        res)))))

However, the guidelines say I shouldn't extend a protocol that I don't own to a type that I don't own.

By the way, (reduce conj [] "Foobar") works as you would expect because String implements clojure.core.protocols/InternalReduce so maybe that's a good precedent.

`find` docstring enhancement proposal

Thu, 11 Dec 2025 12:41:48 +0000

The docstring for clojure.core/find states

Returns the map entry for key, or nil if key not present.

Formatted lower-cased with a space, it is not immediately apparent that 'map entry' is a term of art referring to a specific thing. 'map entry' might be mis-interpreted as a casual synonym for 'the entry of a map associated to a key', i.e., the value.

Proposal #1
Reword the find docstring to be more precise about what is returned.

Returns a clojure.lang.MapEntry containing key and the associated value, or nil if key not present.

Proposal #2
If you don't want to make a commitment to returning a MapEntry, reword to

Returns a sequential collection containing key and the associated value, or nil if key not present.

CVE-warning in org.fressian/fressian <- org.clojure/data.fressian

Fri, 09 Jan 2026 12:45:21 +0000

Dependency Information
When running clj-watson in a project with

org.clojure/data.fressian {:mvn/version "1.1.1"}

I get the following warning, refering to CVE-2018-10054 (relates to a vulnerability in H2 and its usage in older versions of datomic). I assume this is a false positive.

NAME: org.fressian/fressian
VERSION: 0.6.8

DEPENDENCY FOUND IN:

[org.clojure/data.fressian]

FIX SUGGESTION:

Vulnerabilities

SEVERITY: HIGH
IDENTIFIERS: CVE-2018-10054
CVSS: 8.8 (version 3.1)
PATCHED VERSION: Information not available.

clojure.edn and clojure allows keywords with empty ("") namespaces

Fri, 05 Dec 2025 09:56:54 +0000

Following links and snippets are about clojure.edn but because this logic is the same in clojure it also affects clojure reader as well.

Here is how symbol pattern is defined:

[:]?([\D&&[^/]].*/)?(/|[\D&&[^/]][^/]*)

It is eagerly matching prefix until the last slash character, after that it matches symbol name.

Then there is a wrong analysis of matched groups happen: ns is incorrectly set to everything until the last slash with validation that it is not ends with :/

Then in Symbol.intern call there is an another lookup for the first slash to split symbol into namespace and name.

The result is that keywords like this: ":/-/-", end up with namespace set to empty string "".

Looks like the least intrusive way to fix it is to use the same logic to find namespace borders in both places:

during symbol reading, lookup the first / to set ns instead of using the first matching group
in symbol interning the logic is correct

Another option is to use different regular expression:

[:]?([\D&&[^/]][^/]*/)?(/|[\D&&[^/]].*[^/])

This matches symbol prefix til the first slash keeping restriction "name can't end with slash".

shasum not found error when using ./posix-install on linux

Wed, 11 Mar 2026 21:49:11 +0000

I was redeploying an AWS beanstalk application. I was installing clojure using the commands from the clojure install guide for posix

commands:
  01_install_clojure:
    command: |
      curl -L -O https://github.com/clojure/brew-install/releases/latest/download/posix-install.sh
      chmod +x posix-install.sh
      sudo ./posix-install.sh

I believe this used to work, but it now fails with

./posix-install.sh: line 30: shasum: command not found

Using the linux instructions worked just fine. I can provide more info about the linux envorionment, but it was using aws' "Corretto 17 running on 64bit Amazon Linux 2023/4.10.0" platform which is one of the builtin java platforms for beanstalk.

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)

core.unify does not preserve want-occurs? in recursive unify-variable calls

Sat, 16 May 2026 19:09:05 +0000

core.unify does not preserve want-occurs? when recursing from unify-variable-. That is, if unify-varable- calls garner-unifiers, it does not pass itself as the uv-fn parameter, so garner-unifiers will default to unify-variable (which includes an occurs? check). I'm not sure if this was intentional, but I found it surprising. If not intentional, then I believe calls to garner-unifiers in create-var-unification-fn should look like:
(garner-unifiers ~'var-unify ~varp vb# ~expr ~binds)

linux installer fails for non english locale

Thu, 14 May 2026 20:48:19 +0000

"OK" returned by sha256sum may be translated. Better rely on the exit status. Since -p pipefail is used, the pipe to grep could be simply omitted.

clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Mon, 23 Feb 2026 19:43:34 +0000

As of version 1.2.254 of org.clojure/core.cache, using a value-fn that throws will cause an entry to be added to the cache associated with a Delay with :status :failed and the exception as a value.

The code below can be used to compare the behavior between versions 1.1.234 and 1.2.254.

(require '[clojure.core.cache.wrapped :as cw])

(def counter (atom 0))

(defn value-fn [v]
  (prn :value-fn-called)
  (swap! counter inc)
  (if (= @counter 1)
    (throw (ex-info "thrown" {}))
    v))

(def test-cache (cw/lu-cache-factory {} :threshold 10))

(reset! counter 0)
; this will throw
(cw/lookup-or-miss test-cache "throw" value-fn)
; in 1.1.234 this will call value-fn again and not throw; in 1.2.254, it won't call and return
; the cached delay result, which is an exception
(cw/lookup-or-miss test-cache "throw" value-fn)

; evict to force call to value-fn
(cw/evict test-cache "throw")

This is related to work done in CCACHE-65 to avoid cache stampede in multi-threaded applications, and could be related to what has been reported in CMEMOIZE-31.

This was initially reported in Clojurians Slack.

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.

Controlled Bailout, Jira issue 2213

Sat, 21 Mar 2026 10:14:48 +0000

I would like to improve Issue 2213 as follows. Do you think, this makes sense? Shall I become contributor for this?

The new description would be:

When developing Input-Process-Output tools I am often in the situation, that I have a sequence of activities (e.g. opening a file, spec checking a file, calling external tools, creating files), which each could fail in certain ways. Clojure does not have a good way to control such a sequence of activities in a way that all sorts of things, which could go wrong, can be handled comfortably. In imperative programming languages concepts like early exit or bailout are used. These are not not very functional. Unfortunately practical problems are often like this.

The issue is a bit more general and a solution would be nice not only for those who develop such sort of tools. So I can give a simple example.

(let [config-file (get-file-from-network xy)
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

As all these steps can fail, we could instead implement it like this.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file))))

Now the code has suffered already a lot. The sequential nature of the problem is lost. And it is not even doing what we need. We have to report to the user what went wrong.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file)
      :file-has-syntax-errors)
    :file-not-valid-edn)
  :file-cannot be openned)

But this is still not doing what we need. We have to provide more information about each failure. If a file cannot be openned, is it because the file does not exist or we do not have read permissions? And what did the spec check tell us? So we cannot just use nil as a universal failure. We must deliver more information when failing. And we cannot use if-let, either. So we are not even done.

This problem report asks for a better solution for this conceptual challenge.

This example depicts a conflict that should not happen when using an appropriate programming language: First we are able to quickly make a prototype. But in the end the final code has not much in common with the first code any more. The final design is not driven by the problem domain, but by the technical need for an error handling. The need for a bailout mechanism in this example imposes too many huge code changes.

The principal problem with all these solutions is that they coerce a sequence of actions into something which is not a sequence. If your problem is a sequence, then the implementation should also be a sequence.

Idea: Exceptions

As an alternative implementation I went with Exceptions. But it feels wrong, because I am talking about things, that are expected to fail. I cannot just use the Exceptions that are comming out of Java for example when opening a file for read. I need detailed information, what went wrong. If you are a command line tool, it is expected from you, that you provide good error messages. I ended up catching and rethrowing exceptions everywhere in the program.

Idea: Like for/doseq

For me I created a small macro, that extends let. Then I use this syntax:

(let [[config-file error] (get-file-from-network xy)
      :escape     error
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This often allows a surprisingly intuitive code. For example here:

(let [[config-file error-code] (get-file-from-network xy)
      :escape     (if (= error-code :does-not-exist) 
                    :file-xy-does-not-exist)
      :escape     (if (= error-code :io-error)
                    :file-xy-cannot-be-read)
      [config-file error-code] (parse-edn config-file)
      :escape     (if error-code :file-xy-not-legal-edn)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This is inspired by the for/doseq. But I don't claim that this is a good solution for Clojure (although I think so). But I think, the let macro is a good candidate when improving how Clojure can be used for such imperative things.

Idea: Using `if-let`

I also investigated the solution, that was originally proposed by this issue.

(if-let [config-file (get-file-from-network xy)
         config-file (parse-edn config-file)
         config-file-ok? (spec-check config-file)]
  (do-something-with config-file)
  :error)

This problem with this solution is that none of the bindings are available in the else part. That makes it very hard to react accordingly. This is a nice and small new language feature. But I don't think, that in practice it would be of help so often. The example from the original issue was very artificial with mathematical operations that cannot fail. The first draft of this issue with that artificial example does not actally describe a real problem. That is why this issue has completelly been rewritten.

Or course we could still bind everything, which was not failed. But I don't think, we would want that. It would have very interesting consequences to the compiling model.

Idea: Threading macros

As this issue is a about a sequence of activities, a new type of threading macro (e.g. let->) could also be an intuitive solution. But I have not tried anything like this.

Final Words

The principle challenge is, that all these solutions establish a sort of alternative control flow. It is a hard challenge to do this right, especially in a functional language. Like exceptions, that immediatelly exit and magically jump somewhere else. Clojure as a practically language could address this challenge.

Reflection warning when long hint on an argument

Fri, 01 May 2026 19:49:31 +0000

Hi,

I noticed some reflection warning that goes away when removing a hint from fn arguments. I would like to understand the reason for this.

Example, loading this code

(set! *warn-on-reflection* true)

(defn duration-of-seconds
  (^java.time.Duration [^long seconds]
   (java.time.Duration/ofSeconds seconds)))

(defn sleep
  [seconds]
  (Thread/sleep (duration-of-seconds seconds)))

Raises a reflection warning:

call to static method sleep on java.lang.Thread can't be resolved (argument types: java.lang.Object).

However, just removing the ^long hint from the duration-of-seconds fn argument, makes the reflection warning go away.

Thanks!

Consider allowing passing two arguments to sets used as functions

Tue, 26 May 2026 13:44:16 +0000

Similar to how get works with the 3rd not-found argument.

It already works in CLJS:

ClojureScript 1.12.116
cljs.user=> (#{:a} :b :c)
:c

In Clojure, it errors out:

Clojure 1.12.0
user=> (#{:a} :b :c)
Execution error (ArityException) at user/eval1 (REPL:1).
Wrong number of args (2) passed to: clojure.lang.PersistentHashSet

The behavior of `filter` on infinite sequences in Transducers

Sun, 24 May 2026 05:38:39 +0000

Could you tell me where I can find information understanding the difference in behavior below?

user=> (clojure-version)
"1.12.5"
user=> (def iter1 (eduction (filter even?) (range)))
#'user/iter1
user=> (def iter2 (eduction (filter zero?) (range)))
#'user/iter2
user=> (take 1 iter1)
(0)
user=> (take 1 iter2)
;;; Pressed Ctrl-C due to no response

This behavior occurs when the input source is infinite, but I'm confused because I think filter is stateless. Of course, it works fine when Transducers aren't used.

user=> (take 1 (filter even? (range)))
(0)
user=> (take 1 (filter zero? (range)))
(0)

bug bigdec

Fri, 05 Dec 2025 05:09:44 +0000

Optimized str function

Mon, 16 Mar 2026 11:12:53 +0000

Opimized version of str function:

(defn my-str
  (^String [] "")
  (^String [^Object x]
   (if (nil? x) "" (. x (toString))))
  (^String [^Object x & ys]
   (let [sb (StringBuilder. (if (nil? x) "" (. x (toString))))]
     (loop [ys (seq ys)]
       (if-not (nil? ys)
         (let [x (.first ys)]
           (if-not (nil? x)
             (.append sb (.toString ^Object x)))
           (recur (.next ys)))))
     (.toString sb))))

Benchmarks:

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply my-str xs)))

Evaluation count : 2577840 in 60 samples of 42964 calls.

         Execution time mean : 23.611394 µs

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply str xs)))

Evaluation count : 1375200 in 60 samples of 22920 calls.

         Execution time mean : 42.015320 µs

`(:k m)` returns `nil` while `(identical? (first (keys m)) :k)` is `true` — two coexisting `Keyword` instances?

Mon, 11 May 2026 12:59:06 +0000

We're seeing what looks like a violation of the keyword-interning invariant in production. The bug is deterministic (repeats thousands of times in the same order on the same Aleph/Netty thread) and is cleared by recompiling the affected namespaces via nREPL.

(when (and (map? result) (nil? (:payload result)))   ; this WHEN fires
  (let [payload-key (->> (keys result)
                         (filter #(.contains (pr-str %) "payload"))
                         first)
        payload-via-key (when payload-key (get result payload-key))]
    (log/warn {:result-type                   (str (type result))
               :result-keys                   (pr-str (keys result))
               :payload-key-equals-literal?   (= payload-key :payload)
               :payload-key-identical?        (identical? payload-key :payload)
               :payload-via-found-key-nil?    (nil? payload-via-key)}
              "diagnostic")))

Logged values when the bug fires:

{:result-type                   clojure.lang.PersistentArrayMap
 :result-keys                   (:payload :aws-xray)
 :payload-key-equals-literal?   true
 :payload-key-identical?        true
 :payload-via-found-key-nil?    false}

So:

The (:payload result) in the when returned nil.
A few lines later, the diagnostic body proves that the first key in (keys result) IS the body-site :payload literal by identity (and therefore by =, since Keyword inherits Object.equals).
(get result that-key) returns the actual non-nil payload value.

PersistentArrayMap.indexOf uses == for Keyword keys, so the only way (:payload result) returns nil while (keys result) yields a key that is identical? to :payload at a nearby site is if the :payload literal at the WHEN site and the :payload literal at the body site are two different Keyword instances, even though they're written identically in one source-level function.

We compareed the :payload literal with the payload-key and found that both have -

identical content hashcode (-383036092)
identical name bytes [0x70 0x61 0x79 0x6C 0x6F 0x61 0x64]
identical codepoints
same classloader

so it really looks like two distinct interned Keyword instances with the same name.

Environment

Clojure 1.12.4
Eclipse Temurin JDK 25, Shenandoah GC, virtual threads enabled
ARM64 (AWS Graviton, ECS Fargate)
Aleph + Netty, transit-clj/transit-java for decoding

Questions

Could this be a bug in JVM / Clojure runtime?
Has similar behavior been seen in other cases?
What more evidence could we capture?

Is it legal for a namespace to start with a number?

Mon, 23 Feb 2026 18:53:53 +0000

There are rules (informally in the spec, formally in the reader) about disallowing symbols to start with numbers: (def 1asdf 5) However, there aren't rules about namespaces (either middle segments or as the final segment) starting with numbers, leading to their usage in the wild. (For example: https://github.com/marick/Midje/tree/bee206983db22c6dc92044fd7b5b0365bbd44fc6/test/implementation/parsing/0_to_fact_form)

Is this intentional? Should such namespaces be considered legal or not?