Clojure Q&A - Recent activity in Printing

Closed: error printed using pprint in clojure 1.13.0-alpha1

Fri, 03 Jul 2026 17:10:34 +0000

❯ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.13.0-alpha1"}}}'
Clojure 1.13.0-alpha1
user=> (clojure.pprint/pprint :foo)
Execution error (ClassCastException) at clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848/flush (REPL:-1).
class clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 cannot be cast to class clojure.pprint.PrettyFlush (clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 is in unnamed module of loader 'app'; clojure.pprint.PrettyFlush is in unnamed module of loader clojure.lang.DynamicClassLoader @36a58466)
:foo

reported by djblue in #clojure-dev

Answer selected: Why does clojure.core/newline not respect flush-on-newline?

Wed, 21 Aug 2024 15:43:02 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2876

Retagged: clojure.pprint/pprint converts unquote+deref to unquote-splicing

Wed, 21 Aug 2024 15:10:26 +0000

This is very unusual syntax but pretty-printing it does not round-trip.

$ clj -Sforce -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.4"}}}'
Clojure 1.11.4
user=> (require '[clojure.pprint :as pp])
nil
user=> (-> "~ @a" read-string pp/pprint)
~@a
nil
user=> (-> '~ @a)
(clojure.core/unquote (clojure.core/deref a))
user=> (-> '~ @a pp/pprint with-out-str read-string)
(clojure.core/unquote-splicing a)

Reopened: #inst printer uses a ThreadLocal SimpleDateFormat, which is inefficient with virtual threads

Fri, 05 Jul 2024 13:35:29 +0000

The #inst printer uses java.text.SimpleDateFormat, which is not thread-safe. As per common Java practice (of yesteryear), the instance used is folded into a proxied ThreadLocal so all access per thread is thread-safe but no synchronization is needed. In Java 21, this is not ideal because virtual threads are numerous and there is little reuse within a single virtual thread, as there would have been before in a pooled non-virtual thread.

Instead, we should use the immutable formatter provided since Java 8 in java.time.format.DateTimeFormatter and not use a ThreadLocal for this.

Closed: inst changes old dates in Clojure 1.12 alpha10

Sun, 02 Jun 2024 18:58:17 +0000

UPDATE:

https://clojure.org/news/2024/05/23/clojure-1-12-alpha12

Alpha12 reverted the change that caused this issue. This discussion is therefore obsolete.

I just noticed that Clojure 1.12 alpha10 has changed the way old #inst dates are created. As far as I can tell, Java is trying to adjust old dates before the Gregorian calendar was introduced.

In Clojure 1.11.3

user-> #inst "1582-02-24"
#inst "1582-02-24T00:00:00.000-00:00"

In Clojure 1.12-alpha10

user=> #inst "1582-02-24"
#inst "1582-03-06T00:00:00.000-00:00"

I found this when I ran some generative tests on an old project that tested dates. I'm changing my tests to look only at this millennium, which is fine for my application. I don't think Clojure should necessarily do anything to mitigate this change. I just thought it was worth a mention in case someone else bumps into it.

Updated to Clojure 1.12 alpha 11:

user=> (use 'clojure.instant)
nil
user=> (read-instant-date "1582-02-24")
#inst "1582-03-06T00:00:00.000-00:00"
user=> (read-instant-calendar "1582-02-24")
#inst "1582-02-24T00:00:00.000+00:00"
user=> (read-instant-timestamp "1582-02-24")
#inst "1582-03-06T00:00:00.000000000-00:00"

Commented: is '(CID (pr-str my-map)) unambiguously defined?

Tue, 13 Feb 2024 14:35:31 +0000

(This message assumes that you want to calculate a hash/digest function D with the property that for any two unordered sets s1, s2, if (= s1 s2) is true, then (= (D s1) (D s2)) is also true.
Similarly for unordered Clojure maps.)

Note that it is perfectly possible to develop a digest/hash function that is deterministic for unordered objects like unordered sets and Clojure maps. In fact, `clojure.core/hash` is one such function. Such a function must always produce the same result regardless of the order of its elements (for a set) or key/value pairs (for a Clojure map). That puts restrictions on how the function is calculated, and many functions used for digests are _not_ appropriate for that purpose.

If you want to use a hash/digest function where changing the order of elements given to it as input causes the output of that function to change, then I would suggest you are not going to get a result that you will want to use.

Commented: clojure.pprint/pprint bug when using the code-dispatch table

Sat, 02 Dec 2023 00:58:14 +0000

You can follow the contributor instructions [here](https://clojure.org/dev/dev) if you would like. There is no pressure to do so, I just wanted to suggest it since you had already worked out a possible fix.

Edited: print-method is inconsistent with regard to clojure.pprint with print-level

Thu, 28 Sep 2023 16:28:55 +0000

Repro:

;; print-method

user=> (binding [*print-level* 1]
         (prn {:a 1 :b 2}))
{:a 1, :b 2}
nil

user=> (binding [*print-level* 1]
         (prn {:a {:b 2}}))
{:a #}
nil

user=> (binding [*print-level* 1]
         (prn [(clojure.lang.MapEntry. :a 1)
               (clojure.lang.MapEntry. :b 2)]))
[# #]
nil

;; clojure.pprint

user=> (binding [*print-level* 1]
         (clojure.pprint/pprint {:a 1 :b 2}))
{#, #}
nil

user=> (binding [*print-level* 1]
         (clojure.pprint/pprint {:a {:b 2}}))
{#}
nil

user=> (binding [*print-level* 1]
         (clojure.pprint/pprint
           [(clojure.lang.MapEntry. :a 1)
            (clojure.lang.MapEntry. :b 1)]))
[# #]
nil

The docstring for *print-level* says:

If an object is a collection and is at a level greater than or equal to the value bound to print-level, the printer prints '#' to represent it.

A map entry is a collection and in {:a 1, :b 2} is at a level equal to *print-level*, so I would expect prn to have the same output as clojure.pprint.

Commented: problem with Null exception in cl-format

Tue, 22 Aug 2023 02:14:42 +0000

Is this the same thing as https://ask.clojure.org/index.php/10897/is-this-a-bug-in-cl-format ?

Answer selected: Potential issue in ~:[ directive in cl-format.

Thu, 29 Dec 2022 17:01:58 +0000

Looking at this more closely, the conditional expression consumes an argument for the condition so this is the expected behavior.

If you want to skip back and use the consumed arg, ~:* can do that:

user=> (clojure.pprint/cl-format nil "~:[~;~:*~a~]" 100)
"100"
user=> (clojure.pprint/cl-format nil "~:[~;~:*~a~]" nil)
""

Commented: printing and reading date types

Sat, 21 May 2022 10:07:22 +0000

Thanks Alex. I guess it'll remain a mystery for now As you say the most important thing is it's easy for Clojure users to change the reading and printing setup to suit their needs.

Commented: print-table config opts

Fri, 20 May 2022 05:01:14 +0000

Thanks. I have found the 'doric' library does what I need. At least until print-table can be improved

Commented: Is there a way to tell pprint to start with an initial indentation, so that the whole output is indented?

Mon, 25 Apr 2022 15:05:40 +0000

Thank you Fogus!

Commented: cl-format is too slow for production use

Thu, 10 Mar 2022 14:51:52 +0000

compile-format helps but doesn't get anywhere close to e.g. clojure.core/format.

The lack of parity with common lisp's format was central to this thread:

https://www.reddit.com/r/lisp/comments/qho92i/a_casual_clojure_common_lisp_codeperformance/

cl-format needs to be rewritten eliminate a lot of performance that's left on the floor; particularly exclusive use of persistent structures where common lisp's format is not. I started digging into it around the time of writing, but didn't get very far.

Commented: Why Clojure's println does not print Unicode chars properly, while Java's println does?

Thu, 25 Nov 2021 14:57:32 +0000

I have the same problem... on Windows 10 21H1, JDK 16, clj 1.10.3.

Commented: Should pr-str on a function produce valid edn syntax?

Wed, 03 Mar 2021 16:23:45 +0000

Oh definitely -- user-modifiable is key. But explicit scope helps with the principle of least astonishment.

For example, the opts arg to edn/read makes user-defined behavior clear and simple to reason about. In contrast, with print-method, I didn't modify the default behavior, but something else did -- globally. It had a good reason. But it was surprising and non-trivial to track down.

Closed: pprint prints some metadata when print-meta bound to true, but not all

Mon, 18 Jan 2021 16:08:53 +0000

Short example illustrating the behavior:

user=> *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}

user=> (def f1 '(defn foo [^Integer x] ^{:bar 8} (inc x)))
#'user/f1

;; pr shows all metadata, as expected

user=> (binding [*print-meta* true] (pr f1))
^{:line 2, :column 10} (defn foo [^Integer x] ^{:bar 8, :line 2, :column 33} (inc x))nil

;; pprint shows some metadata, but not all

user=> (binding [*print-meta* true] (clojure.pprint/pprint f1))
(defn foo [^Integer x] (inc x))
nil

I have not dug into the details yet, but it appears that this may be because pprint uses pr to show symbols, but not to show collections. Thus pprint shows metadata on symbols, but not collections.

It would be nice if pprint could instead show all metadata, as pr does, when *print-meta* is bound to true.

Answered: Can clojure.core/system-newline be made public?

Thu, 16 Jul 2020 20:50:00 +0000

If its made public, others flavors of clojure like clojurescript will need to implement this

Clojurescript in particular, when running in a browser, may be a bit wired implement it.

So, just access your host with (System/getProperty "line.separator") ;)

Answered: Add support for ~/ directive in cl-format