Clojure Q&A - Recent questions tagged reader

`eval` using functions with metadata

Mon, 01 Jun 2026 14:33:00 +0000

TIL:

(eval (list + 1 2)) ; works
(eval (list (var-get #'+) 1 2)) ; works
(eval (list (fn [a b] (+ a b)) 1 2)) ; works

(defmacro m [] `(~(fn [a b] (+ a b)) 1 2))
(m) ; also works

;; however, if the function has any metadata:
(eval (list (with-meta + {}) 1 2))
;; ^ fails, No matching ctor found for class clojure.lang.AFunction$1

This was unintuitive to discover.

I solved it locally with a little helper:

(defn val->expr [v]
  (if (symbol? v)
    `'~v
    (cond-> v
      (and (fn? v) (not (nil? (meta v))))
      (-> (with-meta nil)
          (list (-> v meta (update-vals val->expr)))
          (conj `with-meta)))))

But this takes special handling. I wonder if something similar would not be possible on a "matching ctor"-level, possibly also for comp, every-pred?, etc. It would be fairly trivial even in userland to have versions of these functions which carry metadata sufficient to recreate expressions, e.g. comp storing the list of functions, and then eval, on encountering No matching ctor found for class clojure.core$comp$fn__5921, can instead pull out the list of functions from that value and evaluate (list* comp (:composed-fns (meta v))) (or some such) instead.

I think this would be great to have in the core lib, at least for metadata and core libs functions like comp, some-fn, every-pred?, and complement.

Note, I'm not talking about adding or changing ctors for these necessarily. A hook for taking unconstructable values and making a constructable value out of them would serve just as well, maybe even a multifn.

Strictly in userland and without core lib support, I suppose the cleanest way to do something like this is a custom protocol and probably monkeypatch some core libs functions (maybe eval?)

So I suppose my questions are:

Is this something you agree would be good to have in general? Or is this by design for some reason I can't see?
Would this be good and practical to have in the corelib? Oughtn't be a breaking change at least
If no, is there currently any sane way to apply my solution in a more systemic way than wrapping every relevant value with a val->expr call?

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?

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.

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.

Aliased namespace in tagged literal

Thu, 11 Dec 2025 20:01:16 +0000

Set up

Tagged literals are defined by setting a namespaced symbol in data_readers.clj (or data_readers.cljc). At load, Clojure merges all of the maps defined in data_readers.clj(c) files found on the classpath into a single map. At read time, the symbol following a # is checked in the merged data readers map, which determines which var to call with the contents of the following form.

For example, #foo/bar [1 2 3] leads to the reader calling the equivalent of (get *data-readers* 'foo/bar).

Problem statement

The tag of a tagged literal must be determined when it is created. The namespace of the chosen tag is set and cannot be changed by a user. Unlike a fully qualified symbol with an aliased namespace, a tagged literal must what was chosen by the author.

As an author of tagged literals, I want to write tags that will not clash with other tags by giving them complex/deep namespaces. For example, {noahtheduke.lazytest/expect noahtheduke.lazytest/expect}.

As a user of tagged literals, I want to alias the namespace of tags and use it in my code. For example:

;; in src/data_readers.clj
{noahtheduke.lazytest/expect noahtheduke.lazytest/expect}

;; in test/noahtheduke/example_project/main-test.clj
(ns noahtheduke.example-project.main-test
  (:require
   [noahtheduke.lazytest :as-alias lt]
   [noahtheduke.lazytest.core :refer [defdescribe it]]))

(defdescribe some-test
  (it "works"
    #lt/expect (= 1 2)))

EDN

This is not related to edn at all and any potential change will be to Clojure itself.

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

[clojure.edn] Leading zeros in numbers

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

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

000000000000042  ;; => 34

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

000000000000042M ;; => 42M

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

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

0.00000000...00
0.0e0001

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

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

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

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

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

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

Inconsistent errors in ratio parsing with either `clojure.edn/read` or `clojure.core/read`

Sat, 22 Nov 2025 17:12:47 +0000

user=> (clojure.edn/read-string "777/2") ;; no surprises
777/2
user=> (clojure.edn/read-string "0777/2") ;; wait, 0777 supposed to be 511
777/2
user=> (clojure.edn/read-string "0x777/2") ;; hexadecimal suddenly throws
Execution error (NumberFormatException) at user/eval175 (REPL:1).
Invalid number: 0x777/2
user=> (clojure.edn/read-string "32r777/2") ;; radix throws as well
Execution error (NumberFormatException) at user/eval177 (REPL:1).
Invalid number: 32r777/2
user=> (clojure.edn/read-string "777N/2") ;; same for BigInt
Execution error (NumberFormatException) at user/eval181 (REPL:1).
Invalid number: 777N/2

Inconsistent part here is octal integer numerator form. I would expect it to fail the same way as the rest of this list but not to silently drop leading zero and turn to not octal form at all.

Second part of the question is: Why other forms throws at all?

Docstring clojure.edn/read-string is misleading

Thu, 20 Nov 2025 15:10:38 +0000

user=> (doc clojure.edn/read-string)
-------------------------
clojure.edn/read-string
([s] [opts s])
Reads one object from the string s. Returns nil when s is nil or empty.
Reads data in the edn format (subset of Clojure data):
http://edn-format.org

opts is a map as per clojure.edn/read

Note Returns nil when s is nil or empty.. But when called with opts without explicit :eof it throws EOF error

user=> (clojure.edn/read-string {} "")
Execution error at user/eval222 (REPL:1).
EOF while reading

And without options it returns nil as expected

user=> (clojure.edn/read-string "")
nil

clojure.edn/read invoke user-supplied reader functions when tagged literal is to be discarded by discard macro

Thu, 20 Nov 2025 14:57:19 +0000

According to edn-format/edn specification

A reader should not call user-supplied tag handlers during the processing of the element to be discarded.

But with clojure.edn/read and its derivatives execute provided reader functions under discard tag:

user=> (clojure.edn/read-string {:readers {'foo (fn [val] (prn "!!!") val)}} "#_ #foo [1 2 3]")
"!!!"
Execution error at user/eval216 (REPL:1).
EOF while reading

The same happen with clojure.core/read and its derivatives:

user=> (binding [*data-readers* {'foo (fn [val] (prn "!!!") val)}] (read-string "#_ #foo [1 2 3]"))
"!!!"
Execution error at user/eval146 (REPL:1).
EOF while reading

I understand that Clojure' reader does not provide explicit description of what is executed during reading out form to be discarded except "The form following #_ is completely skipped by the reader." but I think it is worth to mention that here.

After realisation that this post is not qualifies as "ask"

To summarize:
Is this a bug in clojure edn specification implementation?
Is the edn specification no longer accurate?

Documentation on alternative radix/0-prefixed numbers

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

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

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

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

sending cljs file to repl causes reader exception

Tue, 07 Nov 2023 16:25:47 +0000

I triggered this in real code with a form like this one:

(defn ^:1234567891011 foo []

);

Sending a file with this form (cider-load-buffer in emacs) throws an exception:

StringIndexOutOfBoundsException: Range [44, 34) out of bounds for length 34
	jdk.internal.util.Preconditions$1.apply (Preconditions.java:55)
	jdk.internal.util.Preconditions$1.apply (Preconditions.java:52)
	jdk.internal.util.Preconditions$4.apply (Preconditions.java:213)
	jdk.internal.util.Preconditions$4.apply (Preconditions.java:210)
	jdk.internal.util.Preconditions.outOfBounds (Preconditions.java:98)
	jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:112)
	jdk.internal.util.Preconditions.checkFromToIndex (Preconditions.java:349)
	java.lang.AbstractStringBuilder.substring (AbstractStringBuilder.java:1086)
	java.lang.StringBuilder.substring (StringBuilder.java:91)
	java.lang.AbstractStringBuilder.substring (AbstractStringBuilder.java:1038)
	java.lang.StringBuilder.substring (StringBuilder.java:91)
	clojure.tools.reader.reader-types/peek-source-log (reader_types.clj:248)
	clojure.tools.reader.reader-types/peek-source-log (reader_types.clj:243)
	clojure.tools.reader.reader-types/log-source*/fn--4391 (reader_types.clj:324)
	clojure.core/apply (core.clj:667)
	clojure.core/with-bindings* (core.clj:1990)
	clojure.core/with-bindings* (core.clj:1990)
	clojure.tools.reader.reader-types/log-source* (reader_types.clj:321)
	clojure.tools.reader.reader-types/log-source* (reader_types.clj:316)
	clojure.tools.reader/read+string (reader.clj:1029)
	clojure.tools.reader/read+string (reader.clj:1019)
	shadow.cljs.repl/read-one/fn--17402 (repl.clj:628)
	shadow.cljs.repl/read-one (repl.clj:601)
	shadow.cljs.repl/read-one (repl.clj:578)
	shadow.cljs.repl/process-input (repl.clj:703)
	shadow.cljs.repl/process-input (repl.clj:691)
	shadow.cljs.repl/repl-load-file* (repl.clj:195)
	shadow.cljs.repl/repl-load-file* (repl.clj:173)
	shadow.cljs.repl/repl-load-file (repl.clj:231)
	shadow.cljs.repl/repl-load-file (repl.clj:229)
	shadow.cljs.repl/process-read-result (repl.clj:570)
	shadow.cljs.repl/process-read-result (repl.clj:550)
	shadow.cljs.repl/process-input (repl.clj:713)
	shadow.cljs.repl/process-input (repl.clj:691)
	shadow.cljs.devtools.server.worker.impl/eval17950/fn--17953 (impl.clj:698)
	clojure.lang.MultiFn.invoke (MultiFn.java:234)
	shadow.cljs.devtools.server.util/server-thread/fn--17590/fn--17591/fn--17599 (util.clj:283)
	shadow.cljs.devtools.server.util/server-thread/fn--17590/fn--17591 (util.clj:282)
	shadow.cljs.devtools.server.util/server-thread/fn--17590 (util.clj:255)
	java.lang.Thread.run (Thread.java:1583)

I found this old slack thread where @thheller narrowed it down to tools.reader and provided this repro:

(let [rdr (clojure.tools.reader.reader-types/source-logging-push-back-reader
            "(ns demo.test)\n\n(def foo \"foo\");\n(def bar [])\n")]
  (clojure.tools.reader/read+string rdr)
  (clojure.tools.reader/read+string rdr)
  (clojure.tools.reader/read+string rdr))

Clojure reader fails to suppress cljs namespaced keywords

Fri, 03 Nov 2023 20:57:26 +0000

Reproducible test case:

(ns bug)
(require '[clojure.data.xml :as xml] #?@(:cljs [[clojure.data.xml.js.dom :as dom]]))
(def opts {:features #{:clj} :read-cond :allow})
(read-string opts "#?(:cljs {:a ::dom/Element})")
; Execution error at bug/eval30984 (REPL:534).
; Invalid token: ::dom/Element

Stack trace:

clojure.lang.Util/runtimeException (Util.java:221)
clojure.lang.LispReader/interpretToken (LispReader.java:412)
clojure.lang.LispReader/read (LispReader.java:305)
clojure.lang.LispReader/readDelimitedList (LispReader.java:1398)
clojure.lang.LispReader$MapReader/invoke (LispReader.java:1355)
clojure.lang.LispReader/read (LispReader.java:285)
clojure.lang.LispReader/access$900 (LispReader.java:41)
clojure.lang.LispReader$ConditionalReader/readCondDelimited (LispReader.java:1584)
clojure.lang.LispReader$ConditionalReader/invoke (LispReader.java:1659)
clojure.lang.LispReader$DispatchReader/invoke (LispReader.java:853)
clojure.lang.LispReader/read (LispReader.java:285)
clojure.lang.RT/readString (RT.java:1876)
clojure.core/read-string (core.clj:3817)
clojure.core/read-string (core.clj:3806)
bug/eval30984 (NO_SOURCE_FILE:534)
clojure.lang.Compiler/eval (Compiler.java:7194)

Real-world scenario:

Reading data.xml-0.2.0-alpha8/clojure/data/xml/spec.cljc errors in line 45: https://github.com/clojure/data.xml/blob/v0.2.0-alpha8/src/main/resources/clojure/data/xml/spec.cljc#L45

Note that stack trace is different there:

; Caused by: clojure.lang.ExceptionInfo: [line 45, col 28] Invalid keyword: ::dom/Element. {:type :reader-exception, :ex-kind :reader-error, :file nil, :line 45, :col 28}
; 	at clojure.tools.reader.impl.errors$throw_ex.invokeStatic(errors.clj:34)
; 	at clojure.tools.reader.impl.errors$throw_ex.doInvoke(errors.clj:24)
; 	at clojure.lang.RestFn.invoke(RestFn.java:442)
; 	at clojure.tools.reader.impl.errors$reader_error.invokeStatic(errors.clj:40)
; 	at clojure.tools.reader.impl.errors$reader_error.doInvoke(errors.clj:36)
; 	at clojure.lang.RestFn.invoke(RestFn.java:516)
; 	at clojure.tools.reader.impl.errors$throw_invalid.invokeStatic(errors.clj:97)
; 	at clojure.tools.reader.impl.errors$throw_invalid.invoke(errors.clj:96)
; 	at clojure.tools.reader$read_keyword.invokeStatic(reader.clj:358)
; 	at clojure.tools.reader$read_keyword.invoke(reader.clj:344)
; 	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:935)
; 	at clojure.tools.reader$read_STAR_.invoke(reader.clj:917)
; 	at clojure.tools.reader$read_delimited.invokeStatic(reader.clj:198)
; 	at clojure.tools.reader$read_delimited.invoke(reader.clj:191)
; 	at clojure.tools.reader$read_list.invokeStatic(reader.clj:209)
; 	at clojure.tools.reader$read_list.invoke(reader.clj:205)
; 	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:935)
; 	at clojure.tools.reader$read_STAR_.invoke(reader.clj:917)
; 	at clojure.tools.reader$read_delimited.invokeStatic(reader.clj:198)
; 	at clojure.tools.reader$read_delimited.invoke(reader.clj:191)
; 	at clojure.tools.reader$read_list.invokeStatic(reader.clj:209)
; 	at clojure.tools.reader$read_list.invoke(reader.clj:205)
; 	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:935)
; 	at clojure.tools.reader$read_STAR_.invoke(reader.clj:917)
; 	at clojure.tools.reader$read_suppress.invokeStatic(reader.clj:451)
; 	at clojure.tools.reader$read_suppress.invoke(reader.clj:447)
; 	at clojure.tools.reader$match_feature.invokeStatic(reader.clj:474)
; 	at clojure.tools.reader$match_feature.invoke(reader.clj:458)
; 	at clojure.tools.reader$read_cond_delimited$fn__8556.invoke(reader.clj:485)
; 	at clojure.tools.reader$read_cond_delimited.invokeStatic(reader.clj:480)
; 	at clojure.tools.reader$read_cond_delimited.invoke(reader.clj:477)
; 	at clojure.tools.reader$read_cond.invokeStatic(reader.clj:522)
; 	at clojure.tools.reader$read_cond.invoke(reader.clj:506)
; 	at clojure.tools.reader$read_dispatch.invokeStatic(reader.clj:72)
; 	at clojure.tools.reader$read_dispatch.invoke(reader.clj:68)
; 	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:935)
; 	at clojure.tools.reader$read_STAR_.invoke(reader.clj:917)
; 	at clojure.tools.reader$read.invokeStatic(reader.clj:988)
; 	at clojure.tools.reader$read.invoke(reader.clj:961)

Location data on all IObj

Wed, 20 Sep 2023 14:02:59 +0000

Only lists carry location data, even though most non-primitives implement IObj. Is there a reason for this? Would there be interest in adding location data to all IObj objects at read time?

user=> (meta '(1 2 3))
{:line 1, :column 8}
user=> (meta 'abc)
nil

Why can't unknown tagged literals be embedded in expressions when `default-data-reader-fn` is set to `tagged-literal`?

Tue, 12 Sep 2023 15:50:14 +0000

When setting *default-data-reader-fn* to tagged-literal (as suggested in https://clojure.org/reference/reader#_default_data_reader_function) in a REPL like so:

user=> (set! *default-data-reader-fn* tagged-literal)

As advertised, the REPL can now read unknown tagged literals, e.g.:

user=> #foo 123
#foo 123

However, it fails when embedded in an expresson like so:

user=> (prn #foo 123)
Syntax error compiling fn* at (REPL:1:1).
Can't embed object in code, maybe print-dup not defined: clojure.lang.TaggedLiteral@34b5d34f

The hint in the error message works indeed, so when I provide:

user=> (defmethod print-dup clojure.lang.TaggedLiteral [tl w] (print-method tl w))

The REPL can now successfully read and eval the previous expression:

user=> (prn #foo 123)
#foo 123
nil

Should the print-dup implementation for clojure.lang.TaggedLiteral perhaps be provided by default?

Why different symbol handling by tagged literals vs elements (reader vs edn)

Sun, 27 Aug 2023 21:43:42 +0000

The reader reference docs state "tagged literals are Clojure’s implementation of edn tagged elements."

But the two are different in at least one regard: a symbol produced by a tagged literal will be resolved, but a symbol produced by a tagged element and read by clojure.edn/read-string will not.

This means you can get different output if you read EDN containing a given tag vs. if you use the same tag to produce a literal in your source.

Example:

data_readers.cj

{example/symbolize clojure.core/symbol}

Then:

user> (edn/read-string {:readers {(quote example/symbolize) clojure.core/symbol}}
                       "#example/symbolize\"hello\"")   
hello
user> #example/symbolize "hello"
Syntax error compiling at (*cider-repl clojure/foragr:localhost:46533(clj)*:0:0).
Unable to resolve symbol: hello in this context
user>

Is there any particular reason for this discrepency? Is there a scenario where it would be good to resolve symbols from a tagged literal? And if so, why not do the same from tagged elements and edn/read-string?

Is there a technical reason to avoid `$` in symbol names?

Tue, 28 Mar 2023 03:37:11 +0000

This original version of this post asked about the pipe symbol as well the dollar sign, but there is an answer concerning the pipe symbol here: https://ask.clojure.org/index.php/11627/the-pipe-char-considered-valid-symbol-constituent-character

However, I'm still wondering about the dollar sign, $, which is not explicitly listed as a legal character for symbol names:
https://clojure.org/reference/reader#_symbols
In practice it can be used in symbols:
(def $ 42) $ ;==> 42 (defn a$b [a b] (or a b)) (a$b nil 'foo) ;==> foo
Putting aside the question of whether it's stylistically or pragmatically appropriate (e.g. because of worry about confusing others) to use $ in symbol names (e.g. because of worry about confusing others), is there a technical reason to avoid it?

For example, are there edge cases where using $ in a symbol would cause trouble? Or is it possible that in the future Clojure would use $ as special syntax?

(I have in fact used $ in symbol names in the past.)

Numeric keywords work but not numeric names in qualified keywords?

Fri, 27 Jan 2023 14:40:36 +0000

I've read that the Clojure reader allows reading of numeric keywords because it would cause breaking changes in some libraries to change it, so it seems keywords were not intended to be used in that way. However, is there a breaking reason to not allow the name part of a qualified keyword to be numeric? Since numeric keywords are already being used/allowed?

Use-Case:

I've been playing with modeling in Datomic which encourages namespaced things (that aren't really namespaced) and went with enums for US State FIPS codes since that's what we work with over state names and don't need more than that, i.e., :state/01

This works

(name :01) 
=> "01"

But this doesn't

(name :state/01)
=> Invalid token: :state/01

Read-time evaluation of macros causes errors

Tue, 11 Oct 2022 04:00:39 +0000

Read-time evaluation of functions work as expected. For instance, submitting #=(+ 1 1) to the REPL will indeed return 2. However, read-time evaluation forms such as (if true 1 0) will produce an error. The errors reported are not consistent across macros and special forms.

#=(if true 1 0)
;;=> Can't resolve if
#=(let [] nil)
;;=> Wrong number of args (2) passed to: clojure.core/let

Is this expected behavior? Languages like Common Lisp do not produce errors in this scenario--e.g. the code #.(if t 1 0) returns 1.

request: provide #uri edn extenstion for java.net.URI and goog.Uri out of the box

Sun, 02 Oct 2022 16:43:07 +0000

Q1: is there a particular reason the #uri edn extension was not provided in Clojure, given that clojure and clojurescript implement clojure.core/uri? on java.net.URI and goog.Uri?

Here is a gist documenting how to do it, with tests: HOWTO install #uri reader extension in Clojure/Script

Despite the instruction that "Reader tags without namespace qualifiers are reserved for Clojure" I thought this was safe, because if Clojure were to eventually provide it then: (1) this impl becomes superseded and should be removed; (2) this impl is intended to be the exact implementation that core would provide.

However Borkdude pointed out:

borkdude The problem is that you can't easily undo overriding built-in tags if people have data_readers.cljc stuff on their classpath that override
Dustin Getz Ah so if this extension ends up bundled as a transitive dependency in some lib
borkdude Yes. So even if you wish to remove it, as you know, software isn't killed that easily

Q2: Therefore I request this be considered to someday be provided in core

Q3: Is this the correct impl? (It's my intent to document this once and for all so I appreciate feedback/comments.)

Q4: transit-clj & transit-cljs decline to read java.net.URI and goog.Uri (in disalignment with the clojure.core/uri? predicate), instead reading as cct.Uri. Why is that?

improve syntax errors on tagged-literals

Wed, 28 Sep 2022 13:24:40 +0000

When we write a symbol in the UUID literal, the reported error message is wrong

(as of 1.11.1)

clojure -M -e '#uuid id'
Execution error (AssertionError) at clojure.main/main (main.java:40).
Assert failed: (string? form)

It is wrong because

It is not an execution error. Should be read or syntax error.
It does not include any ex-data: https://clojure.org/reference/repl_and_main#_error_printing

It should be something like this

Reader error (AssertionError) at clojure.uuid/default-uuid-reader (uuid.clj:12).
Assert failed: (string? form)

A second step improvement could be add spec support to data-literals, as macros do.

Syntax error reading #uuid id at (REPL:1)
id - failed: string? at: [:form]

From #clojure-dev slack channel

Alex: You don’t need anything special there - just an instrumented spec on the data reader fn

After run

(s/fdef clojure.uuid/default-uuid-reader :args (s/cat :form string?))
(clojure.spec.test.alpha/instrument `clojure.uuid/default-uuid-reader)

The message turns into

Syntax error reading source at (REPL:2:1).
Call to #'clojure.uuid/default-uuid-reader did not conform to spec.

This is a way better message.

Also, it includes a #:clojure.error{:phase :read-source} in ex-data.
So the fix could be just add a spec to clojure.uuid/default-uuid-reader

Is the pipe char `|` considered a valid symbol constituent character?

Mon, 14 Mar 2022 20:52:00 +0000

Hi,

The pipe char | is accepted as a symbol constituent char both in clj and cljs:

user> {:one|two 'three|four}
{:one|two three|four}

cljs.user> {:one|two 'three|four}
{:one|two three|four}

though it is not mentioned as such in official sources:

https://clojure.org/reference/reader#_symbols
https://github.com/edn-format/edn#symbols

Is it safe to assume it is a valid symbol constituent character since it is accepted by the reader as such?

Thanks

Why do some reader tags throw when evaluated on their own?

Tue, 17 Aug 2021 17:52:04 +0000

For example, take the #ordered/map tag (reader kv defined here, data reader fn). If I eval the following code, I get an exception thrown.

(do #ordered/map ([:b 2] [:a 1] [:d 4]))
Syntax error compiling fn* at (/src/example.clj:6:3).
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7119)
java.lang.IllegalArgumentException: Unable to resolve classname: IPersistentMap
	at clojure.lang.Compiler$HostExpr.tagToClass(Compiler.java:1129)
	at clojure.lang.Compiler.tagClass(Compiler.java:8693)
	at clojure.lang.Compiler$ObjExpr.emitValue(Compiler.java:4810)
	at clojure.lang.Compiler$ObjExpr.emitConstants(Compiler.java:4938)
	at clojure.lang.Compiler$ObjExpr.compile(Compiler.java:4616)
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4110)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7109)
	at clojure.lang.Compiler.analyze(Compiler.java:6793)
	at clojure.lang.Compiler.eval(Compiler.java:7178)
	at clojure.lang.Compiler.eval(Compiler.java:7171)
	at clojure.lang.Compiler.eval(Compiler.java:7136)
	at clojure.core$eval.invokeStatic(core.clj:3202)
	at clojure.core$eval.invoke(core.clj:3198)
	at nrepl.middleware.interruptible_eval$evaluate$fn__939.invoke(interruptible_eval.clj:91)
	at clojure.main$repl$read_eval_print__9110$fn__9113.invoke(main.clj:437)
	at clojure.main$repl$read_eval_print__9110.invoke(main.clj:437)
	at clojure.main$repl$fn__9119.invoke(main.clj:458)
	at clojure.main$repl.invokeStatic(main.clj:458)
	at clojure.main$repl.doInvoke(main.clj:368)
	at clojure.lang.RestFn.invoke(RestFn.java:1523)
	at nrepl.middleware.interruptible_eval$evaluate.invokeStatic(interruptible_eval.clj:84)
	at nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:56)
	at nrepl.middleware.interruptible_eval$interruptible_eval$fn__965$fn__969.invoke(interruptible_eval.clj:155)
	at clojure.lang.AFn.run(AFn.java:22)
	at nrepl.middleware.session$session_exec$main_loop__1067$fn__1071.invoke(session.clj:190)
	at nrepl.middleware.session$session_exec$main_loop__1067.invoke(session.clj:189)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.base/java.lang.Thread.run(Thread.java:829)

The map is read and the data reader fn is called as expected.

(def omap #ordered/map ([:b 2] [:a 1] [:d 4]))
=> #'example/omap
(type omap)
=> flatland.ordered.map.OrderedMap

It's only when eval'ing just the tagged literal that the ex is thrown. Any idea why this is happening?

Why does data-readers require Vars?

Tue, 10 Aug 2021 19:04:31 +0000

edn/read's :readers arg accepts a map of tag symbols to data-reader functions, but *data-readers* requires a map of tag symbols to data-reader Vars (global bindings). I'm just wondering if there is any reason for the discrepancy, because it is a bummer not to be able to use anonymous functions in *data-readers*.

The context is I've made a handful of related reader tags (for tagged literals) that all work similarly, so rather than create 5 near identical reader functions I made 1, with two arity (tag, value), then I made a reader-for function that returns a one-arity function as needed (using partial and the two-arity function). This works just fine for edn/read but when I went to use it in *data-readers* it's a no-go because there is no Var for what comes out of reader-for.

There are several workarounds. For example bind *default-data-reader-fn*and make a function to dispatch to all my readers. Which is not particularly difficult but now I'm left with two artifacts instead of one - the map of readers for edn/read and the function for *default-data-reader-fn*. The map can be leveraged in the function of course. Or as an alternative I can just write the five functions -- or "write" them in a doseq. But the little inconsistencies across how these tags are done is a little baffling. (For example, in addition to the {tag-sym fn} map of :reader and the {tag-sym Var} map of *data-readers*, there is also the {unquoted-tag-sym-in-a-map-literal fn-sym} syntax of data_readers.clj, which despite being a clj file does not seem to afford me the opportunity to do anything dynamic to define readers, just the literal map).

I probably just don't grasp the practicalities/history/logic behind all this, if anyone can shed some light thanks in advance, if not that's fine too.

`source` errors on a function

Wed, 26 May 2021 14:20:10 +0000

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "RELEASE"}}}'
Clojure 1.10.3
user=> (require '[cljs.analyzer.api :as api])
nil
user=> (source api/ns-publics)
Execution error at user/eval138 (REPL:1).
Invalid token: ::ana/namespaces
user=>

Wasn't sure if this was a known issue.

Source of ns-publics:

(defn ns-publics
  "Given a namespace return all the public var analysis maps. Analagous to
  clojure.core/ns-publics but returns var analysis maps not vars."
  ([ns]
   (ns-publics env/*compiler* ns))
  ([state ns]
   {:pre [(symbol? ns)]}
   (->> (merge
          (get-in @state [::ana/namespaces ns :macros])
          (get-in @state [::ana/namespaces ns :defs]))
        (remove (fn [[k v]] (:private v)))
        (into {}))))

Why does #=(println 1) print 1 twice?

Fri, 09 Oct 2020 16:41:37 +0000

Clojure 1.10.1 user=> #=(println 1) 1 1 nil user=> (read-string "#=(println 1)") 1 nil

On Clojure 1.8.0 1 only prints once.

I'm on Ubuntu using the clj tool and Clojure 1.10.1.

Is it possible to create a tagged literal reader for a clojure.core.Vec?

Thu, 03 Sep 2020 03:02:38 +0000

Is it not possible to create a tagged literal for a clojure.core.Vec (that result of the vector-of function)? Creating a reader function for such a tag is trivial, and it works well enough with read-str and EDN readers. But the REPL always winds up holding a clojure.lang.PersistentVector.

This issue came about as I thrash around looking for a round-trip support for a hexstring of bytes with support for idiomatic Clojure (clojure.lang.ISeq and immutability are high priorities).

Despite the promise of (vector-of :byte ...), it's not possible to round trip the byte data cleanly with clojure.core.Vec.
With a tag reader and print-dup writer I can get round-trip ability for JVM native byte arrays, but they don't support clojure.lang.ISeq and they're mutable.
Regular vectors are heterogeneous and I can't safely appropriate
print-dup for them to achieve my goals.

None of these options are attractive.

Enhance the reader so the readtable is available to the user?

Fri, 10 Jul 2020 16:44:37 +0000

Is the Clojure team interested in having someone enhance the reader so that the readtable is available to the user? This would allow users to create readtables, specify read macros and dispatching read macros, and install a readtable as the current one.

Clarify the position of :/ as a keyword

Thu, 09 Jul 2020 06:36:27 +0000

The Clojure and Clojure reader both accept :/ as a keyword, and test.check generates it. From what I could gather from conversations on Slack however it does not seem to be officially considered valid. For example in this thread, which mentions there was an earlier discussion in clojure-dev, but unfortunately I was not able to find it.

It was suggested to remove it from test.check (TCHECK-155) which was closed with a call to authority and quote from Alex Miller, however Alex has also stated that he considers this a test.check bug.

The quote in TCHECK-155 also mentions that "clojurescript should fix its weirdness", but I could not find the original conversation so I'm not sure what this refers to or if there's a ticket. I did find that clojurescript behaves differently than clojure in at least one way

(name (keyword "/")) ;;clj => "" ;;cljs => "/"

I guess my question is, is :/ considered a) valid, b) invalid, or c) undefined / left for future expansion, in EDN and/or in Clojure?

If it is a) valid, is it then safe to say that (name (keyword "/")) is a clojurescript bug?

If it is b) or c), does that mean that TCHECK-155 should be reopened?

Thanks!

reader conditionals for javascript flavors

Mon, 15 Jun 2020 00:22:36 +0000

Why doesn't clojure have reader conditional for nodejs and browser? They are very different environments with different utilities and libraries.

Currently I'm doing this

#?(:cljs (def is-browser
           (exists? js/window)))
#?(:cljs (if (not is-browser)
           (require 'http)))

Is there a better way?

How hard is it for Clojure to have readable closure?

Fri, 22 May 2020 12:52:48 +0000

The language's name is obviously derived from "closure", yet readable closures seem to be Elisp unique feature.
How hard is it for Clojure to have such ability? Of course many types can't have their readable stringified form, but what about closures containing the ones that can?

How to read namespaced keywords with clojure.tools.reader/read?

Mon, 18 Nov 2019 14:04:04 +0000

I'm using clojure.tools.reader/read for reading clojure and cljs forms from files.

Everything works fine but reading namespaced keywords like ::keyword get read as :user/keyword.

I know the reader uses ns dynamic var to figure out the current namespace for reading symbols and keywords but I don't know how to use it to read a non existing namespace, like the one from the file I'm just reading.

I'm trying a (in-ns file-ns-symbol) before doing the read so it creates the ns before reading and it works but sometimes I'm getting java.lang.IllegalStateException: Can't change/establish root binding of: *ns* with set

Just doing

(binding [*ns* file-ns-symbol]
  (reader/read ...))

doesn't work since it will try to call (the-ns file-ns-symbol) for a ns that doesn't exist.

Any ideas or pointers on how to do this?

Thanks!

Possibility to ignore read-eval?

Wed, 09 Oct 2019 13:37:20 +0000

I was wondering if there is a possibility to read arbitrary clojure code but sort of ignore the read-eval feature. So instead of throwing an error when *read-eval* is false, it just ignores it. Something along the lines of

(require '[clojure.tools.reader :as r])
(require '[clojure.tools.reader.reader-types :as t])
(binding [r/*ignore-read-eval* true]
  (r/read (t/source-logging-push-back-reader "#=(+ 3 4)")))
=> (read-eval (+ 3 4))

I am mainly interested in the column/line info of the metadata, so if this is out of scope for the library or there is a better way to this feel free to point me somewhere else. Also happy to do a pull request if that is wanted.

cljs.reader/read-string fails for a input that clojure read-string accepts

Tue, 01 Oct 2019 20:29:32 +0000

 => (cljs.reader/read-string "(re-matches #\".*ClojureScript \\d+\\.\\d+\\.\\d+ (.*)$\")")

Error: Unsupported escape character: \d.
    at new cljs$core$ExceptionInfo (/js/cljs-runtime/cljs.core.js:37198:10)
    at Function.eval [as cljs$core$IFn$_invoke$arity$3] (/js/cljs-runtime/cljs.core.js:37259:9)
    at Function.eval [as cljs$core$IFn$_invoke$arity$2] (/js/cljs-runtime/cljs.core.js:37255:26)
    at Function.eval [as cljs$core$IFn$_invoke$arity$variadic] (/js/cljs-runtime/cljs.tools.reader.impl.errors.js:52:25)
    at Function.eval [as cljs$core$IFn$_invoke$arity$variadic] (/js/cljs-runtime/cljs.tools.reader.impl.errors.js:92:47)
    at Object.cljs$tools$reader$impl$errors$throw_bad_escape_char [as throw_bad_escape_char] (/js/cljs-runtime/cljs.tools.reader.impl.errors.js:321:51)
    at Object.cljs$tools$reader$edn$escape_char [as escape_char] (/js/cljs-runtime/cljs.tools.reader.edn.js:470:38)
    at eval (/js/cljs-runtime/cljs.tools.reader.edn.js:485:39)
    at cljs$tools$reader$edn$read_string_STAR_ (/js/cljs-runtime/cljs.tools.reader.edn.js:488:3)

But same input in clojure :

=> (read-string "(re-matches #\".*ClojureScript \\d+\\.\\d+\\.\\d+ (.*)$\")")

(re-matches #".*ClojureScript \d+\.\d+\.\d+ (.*)$")

Also :

(cljs.reader/read-string "(re-matches #\"hello\")")

doesn't read with cljs.reader/read-string while it reads with clojure read-string

Clojure Q&A - Recent questions tagged reader

`eval` using functions with metadata

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

Is it valid for metadata to have metadata?

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

Aliased namespace in tagged literal

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

[clojure.edn] Leading zeros in numbers

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

Inconsistent errors in ratio parsing with either `clojure.edn/read` or `clojure.core/read`

Docstring clojure.edn/read-string is misleading

clojure.edn/read invoke user-supplied reader functions when tagged literal is to be discarded by discard macro

Documentation on alternative radix/0-prefixed numbers

sending cljs file to repl causes reader exception

Clojure reader fails to suppress cljs namespaced keywords

Location data on all IObj

Why can't unknown tagged literals be embedded in expressions when `*default-data-reader-fn*` is set to `tagged-literal`?

Why different symbol handling by tagged literals vs elements (reader vs edn)

Is there a technical reason to avoid `$` in symbol names?

Numeric keywords work but not numeric names in qualified keywords?

Read-time evaluation of macros causes errors

request: provide #uri edn extenstion for java.net.URI and goog.Uri out of the box

improve syntax errors on tagged-literals

Is the pipe char `|` considered a valid symbol constituent character?

Why do some reader tags throw when evaluated on their own?

Why does *data-readers* require Vars?

`source` errors on a function

Why does #=(println 1) print 1 twice?

Is it possible to create a tagged literal reader for a clojure.core.Vec?

Enhance the reader so the readtable is available to the user?

Clarify the position of :/ as a keyword

reader conditionals for javascript flavors

How hard is it for Clojure to have readable closure?

How to read namespaced keywords with clojure.tools.reader/read?

Possibility to ignore read-eval?

cljs.reader/read-string fails for a input that clojure read-string accepts

Why can't unknown tagged literals be embedded in expressions when `default-data-reader-fn` is set to `tagged-literal`?

Why does data-readers require Vars?