Clojure Q&A - Recent questions tagged possible bug

Possible bug in conditional with NaN comparison

Sat, 11 Jul 2026 15:01:23 +0000

I encountered this possible bug while running a property-based test suite in a ClojureCLR project. Given a comparison between NaN in an if expression, it seemingly takes the wrong branch.

Clojure (CLR)

λ cljr
Clojure core loaded in 837 milliseconds.
Starting main
Clojure core loaded in 409 milliseconds.
Clojure 1.12.2
user=> (<= ##NaN ##NaN)
false
user=> (if (<= ##NaN ##NaN) true false)
true
user=> (let [t (<= ##NaN ##NaN)] (if t true false))
false

user=> (>= ##NaN ##NaN)
false
user=> (if (>= ##NaN ##NaN) true false)
true
user=> (let [t (>= ##NaN ##NaN)] (if t true false))
false

I wasn't able to replicate the issue on Clojure (JVM), C#, or F#.

Clojure (JVM)

λ clj
Clojure 1.12.0
user=> (<= ##NaN ##NaN)
false
user=> (if (<= ##NaN ##NaN) true false)
false
user=> (let [t (<= ##NaN ##NaN)] (if t true false))
false

using System;
					
public class Program
{
	public static void Main()
	{
		Console.WriteLine(Double.NaN <= Double.NaN);
		if (Double.NaN <= Double.NaN) {
			Console.WriteLine(true);
		} else {
			Console.WriteLine(false);
		}
		var t = Double.NaN <= Double.NaN;
		if (t) {
			Console.WriteLine(true);
		} else {
			Console.WriteLine(false);
		}
	}
}

False
False
False

λ dotnet fsi

> nan <= nan;;                                                                
val it: bool = false

> if (nan <= nan) then true else false;;                          
val it: bool = false

> let t = nan <= nan;;
val t: bool = false

> if t then true else false;;
val it: bool = false

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.

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.

Possible ClojureScript bug: corner case with regex literal compilation

Sun, 21 Sep 2025 02:59:22 +0000

I've found what I believe to be a bug in ClojureScript regarding compilation of certain regex literals to JavaScript, a specific example being #"(?i)".

In some cases, #"(?i)" will be compiled to the JavaScript syntax //i, which is in fact not a JavaScript regex literal, but rather a JavaScript single line comment. This then comments out all remaining code on the same generated line, resulting in a syntax error when the code is run on a JavaScript runtime.

This minimal unit test example demonstrates the issue:

(ns regex-test
(:require [cljs.test :refer-macros [deftest testing is]]))

(deftest failing-test
(testing "Minimal reproduction"
(is (not (nil? #"(?i)")))))

As a side note, it's worth mentioning that (?i) is not a valid native JavaScript regex in the first place, so I assume ClojureScript is trying to emulate compatibility with JVM regexes (where this is valid), and converting it to the nearest valid JS equivalent - either (?i:) (e.g. at the REPL), or //i (in compiled code, but which is syntactically not a JS regex literal at all).