Clojure Q&A - Recent questions in Printing

error printed using pprint in clojure 1.13.0-alpha1

Thu, 02 Jul 2026 20:22:36 +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

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

Mon, 12 Aug 2024 23:25:23 +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)

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

Wed, 07 Aug 2024 23:09:06 +0000

Calling (newline) appends a newline to the output stream but does not flush it *flush-on-newline* is bound to true (the default).

Instead, only clojure.core/prn mentions *flush-on-newline* in its docstring and the check and (flush) call is explicit there.

Why is this?

Also, println does not mention that it Observes *flush-on-newline* like prn does, and it doesn't hint that it calls prn which does, since it says Same as print followed by (newline) which isn't actually true.

inst changes old dates in Clojure 1.12 alpha10

Sun, 28 Apr 2024 21:29:36 +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"

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

Sun, 11 Feb 2024 18:27:28 +0000

is a serial representation of a clojure map unambiguously defined? if i compute CID of 'pr-str' of a clojure map, is it unique?

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

Fri, 10 Nov 2023 14:06:05 +0000

There seams to be a bug in clojure.pprint/pprint when using the code-dispatch table and printing let. It happens on Clojure and ClojureScript.

Clojure 1.11.1
user=> (require '[clojure.pprint :as pp])

user=> 
(binding [pp/*print-pprint-dispatch* pp/code-dispatch]
  (pp/pprint
   '(let)))

((let)) ;; prints some extra parenthesis

(binding [pp/*print-pprint-dispatch* pp/code-dispatch]
  (pp/pprint
   '(let*)))

(let*) ;; doesn't happen when pprinting any other form

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

Thu, 28 Sep 2023 07:02:04 +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.

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

Tue, 26 Sep 2023 21:11:41 +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.

problem with Null exception in cl-format

Wed, 16 Aug 2023 14:36:19 +0000

If the format string ends in ~@, there is code in cl-format to detect this
and issue a format-error. However, that error detection is wrong, and a null exception
happens rather than the format-error being reported.

To reproduce this, simply evaluate the following.

clojure.pprint> (cl-format false "~@")
Execution error (NullPointerException) at nrepl.middleware.interruptible-eval/evaluate$fn$fn (interruptible_eval.clj:87).

I have a fix for this which I'd like to contribute.

Here is the new version of the code compile-directive

(defn- compile-directive [s offset]
  (let [[raw-params [rest offset]] (extract-params s offset)
        [_ [rest offset flags]] (extract-flags rest offset)
        directive (first rest)
        ;; previous version was missing (if directive ...) here thus (format-error ...) never reached
        def (if directive (get directive-table (Character/toUpperCase ^Character directive)))
        params (if def (map-params def (map translate-param raw-params) flags offset))]
    (if (not directive)
      (format-error "Format string ended in the middle of a directive" offset))
    (if (not def)
      (format-error (str "Directive \"" directive "\" is undefined") offset))
    [(struct compiled-directive ((:generator-fn def) params offset) def params offset)
     (let [remainder (subs rest 1) 
           offset (inc offset)
           trim? (and (= \newline (:directive def))
                      (not (:colon params)))
           trim-count (if trim? (prefix-count remainder [\space \tab]) 0)
           remainder (subs remainder trim-count)
           offset (+ offset trim-count)]
       [remainder offset])]))

The old version

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

Thu, 29 Dec 2022 14:30:48 +0000

I am using the cl-format function from the clojure.pprint library. I am using the ~:[ directive as follows:

(cl-format nil "~:[~;~a~]" arg)

When arg is nil, I get the expected empty string as a return value. However, when arg is non-nil, liike 1, I get an error: "Not enough arguments for format definition." When I pass a second arg to the cl-format function:

(cl-format nil "~:[~;~a~]" 1 2)

it prints 2, so it's acting as if it is absorbing the first argument to check for its non-nil character and then passing the second to the internal format directive.

From my reading of both the CL Hyperspec, and the gigamonkies format reference, the ~:[ should not absorb the argument but pass it on to the internal spec for printing. Is this an error in the implementation of cl-format or am I misinterpreting the spec?

I've looked at the source and it sure looks like the navigator argument to execute-sub-format on line 862 of https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/cl_format.clj should be arg-navigator instead.

printing and reading date types

Fri, 20 May 2022 05:31:02 +0000

To my understanding, Clojure's pr function prints objects so that when read back will be = to the original object. My main source for this come s from this talk https://youtu.be/pbodL96HM28?t=216 from Clojure core developer Stuart Sierra ( I cannot find any docs to say what guarantees pr offers).

If this is correct, then pr is not working for java.sql.Timestamp and java.util.Calendar. For example, this returns false.

(let [d (java.sql.Timestamp. 1)]
(= d
(read-string
  (pr-str d))))

Further, Clojure's documentation says , print-dup, when true, means that objects will be printed in a way that preserves their type when read in later

This is not the case for java.sql.Timestamp and java.util.Calendar

`
(binding [*print-dup* true]
(prn (java.sql.Timestamp. 1)))
=> #inst "1970-01-01T00:00:00.001000000-00:00"

As well as being interesting to get some answers to the above, understanding these issues might give some basis for Clojure's support of java.time date types as tracked by https://clojure.atlassian.net/browse/CLJ-2224 .

I understand the above behaviour can be changed by users, but I am asking about the default implementations.

print-table config opts

Thu, 12 May 2022 11:46:04 +0000

Hi,

I find when cell-content widths vary a lot (e.g. in some col, some long strings and some short) that the current right-aligned output is hard to read.

can print-table have opt to left-align output?

Also, I often want to copy output from print-table into a spreadsheet. left-aligning would help (trimming not a one-click thing in spreadsheets afaik), but what might actually help even more is to have e.g. a csv output (so no whitespace padding happens) at all. I can reach for csv lib ofc, but the use case of 'get some clojure data into spreadsheet' is something I might want anywhere anytime, so in the same way that vi editor comes as standard with many linux distros mostly, this would be handy to have.

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

Sat, 23 Apr 2022 21:18:00 +0000

I'd like to pprint a data structure, where the whole thing is printed indented. (As if, for example, I was already some levels deep).

(pprint x)
{:foo ...
 :bar ...}

(pprint-with-indentation x)
    {:foo ...
     :bar ...}

I tried calling pprint-indent before pprint, but that didn't work (or I was using it wrong!)

Stel commented with a solution of adding the indentation after running pprint. This would certainly work; I was looking more specifically to ask if there was a way to get pprint to do it (so that the output would continue to conform to *print-right-margin* etc. without adjusting the margins myself). Of course, if there isn't a way to do that, Stel's solution is a good workaround.

Any ideas of what I could try?

Thanks!

Andrew

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

Wed, 24 Nov 2021 07:53:26 +0000

The repro is very simple, note the correct ║ with Java's println and incorrect ? with Clojure's println:

Clojure 1.10.3
user=> (.println System/out "abc\u2551")
abc║
nil
user=> (println "abc\u2551")
abc?
nil

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

Wed, 03 Mar 2021 03:28:04 +0000

Is the print-method implementation for functions intended to produce valid edn syntax? In some cases, it does not:

user> (require '[org.httpkit.server :as http])
user> (def s (http/run-server (fn [req] {:status 200}) {}))
user> (prn s)
#function[clojure.lang.AFunction/1]

Symbol names can't start with a number, so clojure.lang.AFunction/1 causes a parse error when read back:

user> (clojure.edn/read-string (prn-str s))
Execution error at user/eval7394 (REPL:68).
Invalid token: clojure.lang.AFunction/1

Is this the expected behavior? If so, printing and re-reading data structures that may contain fns can fail.

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

Thu, 16 Jul 2020 19:05:21 +0000

Right now, newline accesses a private var named system-newline which is initialized from the Java system property line.separator. For portability reasons, it would be nice if Clojure made this variable public so that application code could easily access it. Is there any reason to keep it private?

pr botches structmaps containing namespaced keys when print-namespace-maps

Mon, 21 Jan 2019 03:41:30 +0000

{{pr}} misrepresents a structmap containing namespaced-keyword keys. {{pr}} misstates actual keys' values, and includes phantom keys.

user=> (pr-str (struct (create-struct :q/a :q/b :q/c) 1 2 3))
"#:q{:q/a nil, :q/b nil, :q/c nil, :c 3, :b 2, :a 1}"

It worked in Clojure 1.8, and disabling the print-namespace-maps feature appears to work around the problem:

user=> (binding [*print-namespace-maps* false]
(pr-str (struct (create-struct :q/a :q/b :q/c) 1 2 3)))
"{:q/a 1, :q/b 2, :q/c 3}"

By the way: Structmaps are (now as ever) appropriate when the basis is anonymous and computed (not coded) or key order is a significant aspect of the basis. People sometimes cite the reference doc's statement, "Most uses of StructMaps would now be better served by records", but, of course, it is referring only to those uses that are _actually_ better served by records. Record classes can't be anonymous and defrecord needs the basis at compile time; and normal maps do not exhibit a preset key order. Thus the continuing relevance of structmaps.

Add support for ~/ directive in cl-format

Thu, 09 Aug 2018 09:07:50 +0000

clojure.pprint/cl-format does not support the ~/ directive which allows to extend the formatter with custom functions.

The doc at https://clojure.github.io/clojure/doc/clojure/pprint/CommonLispFormat.html mentions that support for ~/ is next up.

This Jira is to ask if someone is willing to contribute that enhancement to it.

'Exception Not enough arguments for format definition' deep inside pprint

Mon, 22 Jan 2018 17:17:19 +0000

My first time submitting a bug. I didn't understand Jira very well; it asked me which project and I couldn't figure out the right project (I assumed ClojureCLR because the pprint issues seem to be tagged 'CLR', but I don't know if ClojureCLR = CLR or even what CLR stands for) and I couldn't figure out if the bug had already been reported (every search seemed to turn up lots of results that were not relevant, didn't include all my search terms). And I didn't see any "Read this before submitting a bug report!!" page like I'd expect for a project of this size. So my apologies if I got this wrong.

Expected behavior:

`
user> (use 'clojure.pprint)
user> (with-pprint-dispatch code-dispatch

     (write '(ns bleh
               (:refer-clojure :only [])
               (:require [blah :refer :all]))
            :pretty true))

(ns bleh
(:refer-clojure :only [])
(:require [blah :refer :all]))
nil
user>
`

Actual behavior:

`
user> (use 'clojure.pprint)
user> (with-pprint-dispatch code-dispatch

     (write '(ns bleh
               (:refer-clojure :only [])
               (:require [blah :refer :all]))
            :pretty true))

Exception Not enough arguments for format definition clojure.pprint/next-arg (cl_format.clj:93)
(ns
`

NPE when print-duping Void/TYPE

Tue, 19 Sep 2017 01:44:16 +0000

`
user=> (binding [*print-dup* true] (print Void/TYPE))

NullPointerException java.io.PrintWriter.write (PrintWriter.java:473)

=(identity user=>

Patch: 0001-CLJ-2238-handle-Void-TYPE-in-print-dup.patch

#clojure/var tag for transmitting var identity

Mon, 22 May 2017 15:00:58 +0000

Currently one can't send vars around in edn. #' is clojure reader specific. Objective is to transmit var identity and bind to same-named var on reading side (a la var serialization support).

Proposed: This is not generic enough to add to edn, so use #clojure/var for tag. Printing may print #clojure/var instead of #' (perhaps via a flag) - needs more assessment. #clojure/var tag reader should be installed in data readers.

Patch: vartag2.patch

Suppress printing namespace map literal syntax when only one namespaced key

Thu, 21 Jul 2016 20:31:13 +0000

Really an aesthetic choice, but right now maps with only a single namespaced key are printed in namespace map literal syntax:

user=> {:my.ns/b 1}
#:my.ns{:b 1}

And that seems unnecessarily complicated (and longer).

*Proposal:* Only print namespace map literal syntax when >1 key is using the same namespace.

*Patch:* clj-1986.patch

cl-format is too slow for production use

Mon, 06 Jun 2016 05:41:02 +0000

Run this example code:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-ns 'clojure.pprint)

(println "Basic output using raw str.")
(time
(doseq [i (range 1000)]
   (apply str (interpose "," [1 2 3]))))

(println "Test 1 - raw cl-format")
(time
(doseq [i (range 1000)]
   (clojure.pprint/cl-format nil "~{~D~^,~}" [1 2 3])))
;; ==> "Elapsed time: 231.345 msecs"

(println "Test 2 - call on the compiled format")
(def myx
  (compile-format "~{~D~^,~}"))

(time
(doseq [i (range 1000)]
   (clojure.pprint/cl-format nil myx [1 2 3])))

(println "Test 3 - using a formatter")
(def myy
  (formatter "~{~D~^,~}"))

(time
(doseq [i (range 1000)]
   (myy nil myx [1 2 3])))

(time
(dotimes (i 100000)
   (format nil "~{~D~^,~}" '(1 2 3))))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

It will print something like this:

Basic output using raw str.
"Elapsed time: 2.402 msecs"
Test 1 - raw cl-format
"Elapsed time: 194.405 msecs"
Test 2 - call on the compiled format
"Elapsed time: 87.271 msecs"
Test 3 - using a formatter
"Elapsed time: 199.318 msecs"

So raw `str' is ~ 100X faster.

For reference, on the same hardware, using
SBCL Common Lisp, this test runs in < 1 ms.

There are (at least) 2 problems here:

1. cl-format function begins with a line like:

    let [compiled-format (if (string? format-in) (compile-format format-in) format-in)

   But there is no api to pass in a compiled-format into it; (as compile-format
   is a private function, so can't be used at large) so this is kind of useless.

2. Even using a precompiled formatter is way too slow.

Suggested fix: none, except perhaps warning unwary users that this
function is simply not suitable for tight loops, and should only be
used to pretty print user input strings, etc.

Thank you

enhance pprint to print type for defrecord (as in pr)

Fri, 05 Feb 2016 19:36:21 +0000

pprint currently doesn't print the names of defrecord types, instead printing just the underlying map. This is in contrast to pr-str/println. This ticket proposes that the behaviour of pprint is changed to match pr-str and println's.

More discussion at https://groups.google.com/forum/#!topic/clojure-dev/lRDG6a5eE-s

user=> (defrecord myrec [a b])
user.myrec
user=> (->myrec 1 2)
#user.myrec{:a 1, :b 2}
user=> (pr-str (->myrec 1 2))
"#user.myrec{:a 1, :b 2}"
user=> (println (->myrec 1 2))
#user.myrec{:a 1, :b 2}
nil
user=> (pprint (->myrec 1 2))
{:a 1, :b 2}
nil

*Approach:* Add new IRecord case to pprint's simple-dispatch mode. Extract guts of pprint-map to pprint-map-kvs and call it from both existing pprint-map and new pprint-record. Set multimethod preference for IRecord version. Added test.

user=> (pprint (->myrec 1 2))
#user.myrec{:a 1, :b 2}

*Patch:* CLJ-1890-pprint-records-2.patch

*Prescreened by:* Alex Miller

*Also see:* CLJS-1753

Add the ability to rename columns in clojure.pprint/print-table

Thu, 24 Dec 2015 06:26:52 +0000

I suggest adding the ability to rename columns in {{clojure.pprint/print-table}}, with the following interface:

(print-table [[:b "column b"] [:a "a"]]
                 [{:a 1 :b {:a 'is-a} :c ["hi" "there"]}
                  {:b 5 :a 7 :c "dog" :d -700}])

| column b | a |
|-----------+----|
| {:a is-a} | 1 |
|         5 | 7 |

cl-format does not respect aesthetic ~A with a keyword

Sat, 26 Sep 2015 13:54:45 +0000

In Common Lisp, (format nil "~a" :A) returns "A". However, in Clojure, it returns with the colon:

(clojure.pprint/cl-format false "~a" :A) => ":A"

Replace refs in pprint

Thu, 13 Aug 2015 14:09:36 +0000

I noticed that pprint uses refs and dosync transactions in a number of places, which seems unlikely to be necessary. It seems like these could be replaced by atoms, or even volatiles, given that printing typically happens in a single thread. Presumably this would improve performance of pprint significantly.

pr-str captures stdout from printing side-effects of lazily evaluated expressions.

Tue, 23 Sep 2014 15:45:01 +0000

Because clojure.core/pr-str uses with-out-str to capture the output of pr (and pr cannot be parsed a writable thing - just uses out).

If you pr-str the result of something lazy you can get side-effects written to stdout with println interspersed with the output. For example in my case I was extracting benchmarks from the library criterium and trying to print the data structure to the file. The solution would be to provide an overload of pr/pr-str that takes a writer. I note that pr-on provides some of the functionality but it is private.

This is an ugly bug when you're trying to persist program output in EDN, because the randomly interspersed stdout messages make it invalid for read-string. We shouldn't need our functions to be pure for pr-str to work as expected.

I've omitted a patch because although I think a fix is straight-forward I'm not sure quite where it should go (e.g. make pr-on public, change pr, change pr-str)

Option to print type info

Mon, 21 Jul 2014 17:07:49 +0000

I've had an issue with defrecord-types being converted into ordinary maps somewhere, which was relatively hard to track down inside a deep structure since they are pprinted as the same thing by default.
The following code patches into the pprint dispatch and prints the type around values; it turned out to be quite useful, but feels hackish.
Maybe something like that would be useful to integrate into clojure.pprint directly (there are a number of cosmetic options already), i.e. into clojure.pprint/write-out.

Only printing {{(type)}} may not be enough in some cases; so an option to print all metadata would be nice.
Maybe something like {{:metadata nil}} as default, {{:metadata :type}} to print types (but also for non-IMetas, using {{(type)}} and {{:metadata true}} to print metadata for IMetas using {{(meta)}}.

(defn pprint-with-type
  ([object] (pprint object *out*))
  ([object writer]
   ; keep original dispatch.
   ; calling it directly will print only that object,
   ; but return to our dispatch for subobjects.
   (let [dispatch clojure.pprint/*print-pprint-dispatch*]
     (binding [clojure.pprint/*print-pprint-dispatch*
               (fn [obj]
                 (if (instance? clojure.lang.IMeta obj)
                   (do (print "^{:type ")
                       (dispatch (type obj))
                       (print "} ")
                       (clojure.pprint/pprint-newline :fill)
                       (dispatch obj))
                   (do (print "(^:type ")
                       (dispatch (type obj))
                       (print " ")
                       (clojure.pprint/pprint-newline :fill)
                       (dispatch obj)
                       (print ")"))))]
       (clojure.pprint/pprint object writer)))))

cl-format throws ClassCastException: Writer cannot be cast to Future/IDeref

Mon, 07 Jul 2014 16:55:27 +0000

Using \~I and \~_ etc fails in many situations, the most trivial one being:

Clojure 1.6.0 and 1.5.1:

user=> (clojure.pprint/cl-format true "~I") ClassCastException java.io.PrintWriter cannot be cast to java.util.concurrent.Future clojure.core/deref-future (core.clj:2180) user=> (clojure.pprint/cl-format nil "~I") ClassCastException java.io.StringWriter cannot be cast to java.util.concurrent.Future clojure.core/deref-future (core.clj:2180) user=> (clojure.pprint/cl-format nil "~_") ClassCastException java.io.StringWriter cannot be cast to java.util.concurrent.Future clojure.core/deref-future (core.clj:2180)

Clojure 1.4.0

user=> (clojure.pprint/cl-format true "~I") ClassCastException java.io.OutputStreamWriter cannot be cast to clojure.lang.IDeref clojure.core/deref (core.clj:2080) user=> (clojure.pprint/cl-format nil "~I") ClassCastException java.io.StringWriter cannot be cast to clojure.lang.IDeref clojure.core/deref (core.clj:2080) user=> (clojure.pprint/cl-format nil "~_") ClassCastException java.io.StringWriter cannot be cast to clojure.lang.IDeref clojure.core/deref (core.clj:2080)

These work in other implementations, i.e. clisp, creating empty output in these trivial cases:

> (format t "~I") NIL > (format nil "~I") "" > (format nil "~_") ""

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

Fri, 13 Jun 2014 17:02:46 +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.

print-dup's handling of metadata typehint is unreadable in some circumstances

Thu, 03 Oct 2013 04:22:22 +0000

With print-dup true, if an object being printed has a metadata map with only a :tag key, the printer renders it as "^value". This can cause an IllegalArgumentException if you try to read the printed string back in, in some circumstances. E.g.

user=> (read-string (let [ge (with-meta (gensym) {:tag Object})] (binding [*print-dup* true] (pr-str ge)))) IllegalArgumentException Metadata must be Symbol,Keyword,String or Map clojure.lang.LispReader$MetaReader.invoke (LispReader.java:732)

This is causing problems with sleight/riddley's (link: 1) handling of the (case) macro, which drops a type-hint on a gensym it incorporates in the form it returns. When sleight tries to reserialize a macroexpanded (case) form from riddley, it fails as demonstrated above. E.g.

user=> (read-string (binding [*print-dup* true] (pr-str (macroexpand '(case 1 1 1))))) user=> IllegalArgumentException Metadata must be Symbol,Keyword,String or Map clojure.lang.LispReader$MetaReader.invoke (LispReader.java:732)

The attached patch corrects this by making core_print.clj's print-meta always print out the full metadata map if print-dup is true. The patch also contains a test for this case.

(link: 1) https://github.com/ztellman/sleight https://github.com/ztellman/riddley

print-table displays tables incorrectly when one of the cells is a string that has newlines

Tue, 09 Jul 2013 20:02:30 +0000

When using print-table to print an ASCII table to stdout, the table display breaks if any of the values is a string with any new lines in it. For example:

`
user=> (print-table [{:a "test" :b "test\ntest2"}])

| :a | :b |
|------+------------|
| test | test
test2 |
nil
`

I would expect the output to look something like this:

`
user=> (print-table [{:a "test" :b "test\ntest2"}])

| :a | :b |
|------+------------|
| test | test +
| | test2 |
nil
`

The + symbol on the right border means that the row continues over multiple lines. This is similar to how the PostgreSQL psql tool displays table with multi-line rows:

`
user=# select 'test' col1, E'test\ntest2\ntest3' col2;
col1 | col2
------+-------
test | test +

  | test2+
  | test3

(1 row)

Time: 0.776 ms
`

clojure.pprint/code-dispatch breaks on certain types of anonymous functions

Sun, 10 Mar 2013 22:40:12 +0000

`
(with-out-str
(with-pprint-dispatch code-dispatch

                    (pp/pprint (read-string "(fn* [x] x)"))))

breaks because the format string here: https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/dispatch.clj#L378 expects a sequence. In the case of (fn* (link: x) x) it is passed a symbol.

Make print-sequential interruptible

Fri, 21 Sep 2012 22:10:46 +0000

This allows print-sequential to be interrupted by Thread.interrupt(), rather than requiring clients to resort to Thread.stop(). This is especially helpful when printing very large sequences.

See also clojure-dev discussion at https://groups.google.com/d/topic/clojure-dev/vs0RNUQXiYE/discussion

Patch: clj-1073-add-print-interruptibly-patch-v2.txt

Approach:

Add a new var print-interruptibly, similar to print-length, print-dup, etc. Its default is false. When true, (Thread/interrupted) is checked for after printing each element of a sequence. If true, the writer is flushed and an InterruptedIOException is thrown.

An alternative patch proposed earlier did not include print-interruptibly, but simply always checked (Thread/interrupted) after printing each element of a sequence. Benchmark tests showed that this could slow down printing of long sequences by about 10%. The approach in the proposed patch only incurs this slowdown if print-interruptibly is true. When false, there is no significant slowdown measured in benchmarks.

pr-str and read-string don't handle @ symbols inside keywords properly

Thu, 26 Jul 2012 17:25:39 +0000

user=> (read-string (pr-str {(keyword "key@other") :stuff}))
RuntimeException Map literal must contain an even number of forms clojure.lang.Util.runtimeException (Util.java:170)

pr-str emits "{:key@other :stuff}", which read-string fails to interpret correctly. Either pr-str needs to escape the @ symbol, or read-string needs to handle the symbol inside a keyword.

Background: I'm passing a map with email addresses as keys through Storm bolts, which require a thrift-serializable form. Using the pr-str/read-string combo fails on these keys, so I've fallen back to JSON serialization.

clojure.pprint uses the old-style metadata.

Mon, 26 Sep 2011 08:35:36 +0000

I was looking through the implementation of clojure.pprint.* and found that it still uses the old-style metadata to mark vars as private - ^{:private true} instead of ^:private.

I have migrated the metadata to the new style in the attached trivial patch, which can be used in case this is deemed to be an issue.

FWIW, there are some other namespaces which use the old-style metadata as well; I am willing to fix those as well.

hash-maps print-dup as literal, thus can be read as array-maps

Tue, 07 Jun 2011 21:14:49 +0000

Per Rich in CLJ-799: "The point of print-dup is type preservation"

user=> (hash-map :k :v)
{:k :v}
user=> (type *1)
clojure.lang.PersistentHashMap
user=> (binding [*print-dup* true] (print-str *2))
"{:k :v}"
user=> (read-string *1)
{:k :v}
user=> (type *1)
clojure.lang.PersistentArrayMap

The cause is due to {{RT.map}} conditionally creating an array-map if the size is within the {{PersistentArrayMap.HASHTABLE_THRESHOLD}}.

(pprint-newline :fill) is not handled correctly

Wed, 12 May 2010 15:45:00 +0000

Filled pretty printing (where we try to fit as many elements on a line as possible) is being too aggressive as we can see when we try to print the following array:

user> (binding [*print-right-margin* 20] (pprint (int-array (range 10))))

Produces:

[0,
1,
2,
3,
4, 5, 6, 7, 8, 9]

Rather than

[0, 1, 2, 3, 4,
5, 6, 7, 8, 9]

or something like that. (I haven't worked through the exact correct representation for this case).

We currently only use :fill style newlines for native java arrays.