Clojure Q&A - Recent questions tagged tagged literal

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/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?

Tagged literals in Clojure CLI arguments and deps.edn

Tue, 12 Sep 2023 21:02:35 +0000

As it stands there is no way for the Clojure CLI to extend the reader with tagged literals for use within arguments or deps.edn.

I propose that some mechanism for this should be added, which can enable additional tooling to use the intended use case of putting data within aliases in deps.edn where they otherwise would be restricted by data readers.

An example of a current project which would benefit from this is Codox, which has support for regular expression based filters on namespaces to be documented, however as the default EDN reader does not include support for regular expressions, this feature is unusable.

If tagged literals support was added to the Clojure CLI, this problem could be resolved by a #jvm/regex tag or similar being added for that usecase.

If this feature is added it should also be considered what happens when a deps.edn file or argument to the CLI includes a tagged literal which is not bound in the current invocation.

There are multiple ways that support could be added to the CLI, and below I present a few of my own thoughts on the matter, but this is not a request for this to be the way that the feature is implemented, just some ideas.

Tagged literals could be added via aliases in the user deps.edn which are then used by default in all projects
Tagged literals could be specified by an environment variable, which users can then set with direnv or other tooling

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?

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

Should Clojure automatically load namespaces of vars defined in data_readers.clj?

Mon, 22 Nov 2021 14:29:20 +0000

I thought Clojure automatically loads namespaces for vars used to read tagged literals in the source code, but apparently it isn't.

Given a library that defines data_readers.clj with following content:

{foo/bar my.library.foo/bar
 foo/baz my.library/baz}

An attempt to read #foo/bar [1 2 3] will result in this exception:

Syntax error reading source at (REPL:1:69).
Attempting to call unbound fn: #'my.library.foo/bar

To avoid this exception you need to require the library namespace before using reader tags.

It would be more convenient to be able to use library reader tags just by adding it to the classpath without explicit require step.

I don't know why it's made this way...

If the reasoning is clojure.core startup time, perhaps the actual load of the var ns might happen at the first tagged literal read time?
If the reasoning is security implications of unexpected code execution, maybe the behavior of requiring data reader namespaces could be configured with *read-eval*?

Clojurescript core.async go block incorrectly handles records returned from tagged literals

Fri, 27 Aug 2021 18:53:31 +0000

In clojurescript, I have a data reader that returns a record from a tagged literal:

(ns x.x)

(defrecord X [y])

(defn make-x [y] (->X y))

data_readers.cljc:

{x x.x/make-x}

This doesn't work correctly inside of go blocks:

(println "outside of go:" #x"a")
(go
  (println "inside of go:" (<! (go #x"b"))))

Results in:

outside of go: #x.x.X{:y a}
inside of go: {:y b}

@hiredman on the clojurians slack pointed out the issue:

what is happening is here
https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/ioc_macros.clj#L403

map? is returning true so it is compiling your record as a map

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.

Are reader tags supposed to support non-ASCII characters?

Thu, 15 Apr 2021 05:48:03 +0000

I tried defining a Unicode data-literal tag, and was surprised to find that it throws an error:

(defn wrap-λ [expr]
  `(fn [~'%] ~expr))
    
(set! *data-readers*
  (assoc *data-readers*
    'λ #'wrap-λ))

(read-string "#λ(inc %)")
;; => Execution error (ArrayIndexOutOfBoundsException) at lib/eval74486 (REPL:15).
;;    Index 955 out of bounds for length 256

955 is the Unicode codepoint for \λ, and the error suggests it only supports the ASCII range.
The first few lines of the stacktrace:

       LispReader.java:  840  clojure.lang.LispReader$DispatchReader/invoke
       LispReader.java:  285  clojure.lang.LispReader/read
       LispReader.java:  216  clojure.lang.LispReader/read
       LispReader.java:  205  clojure.lang.LispReader/read

Is this expected behavior? Clojurescript does not have the same issue:

(cljs.reader/register-tag-parser! 'λ wrap-λ)
(cljs.reader/read-string "#λ(inc %)")
;; => (cljs.core/fn [% & args] (inc %))

behaviour of data_readers.cljc

Sun, 20 Dec 2020 08:09:53 +0000

update: I have raised this as an issue: https://clojure.atlassian.net/jira/software/c/projects/CLJS/issues/CLJS-3294

I am trying to write a library which provides a set of tagged literals (and their reader fns) for consumption from both clojure and clojurescript.

data_readers.cljc

{foo/bar my.project.foo/bar}

my/project/foo.cljc

    (ns my.project.foo)

(defn bar [x]
  #?(:clj (str "hello! " x)
     :cljs (clj->js x)))

cmd line:

clj --main cljs.main -e "(println #foo/bar \"world\")"

prints "hello, world"

clojurescript compiles+executes the :clj branch in the bar reader fn - as far as I can see there is no way to execute cljs code in a reader. I have also tried having a my/project/foo.cljs (ie cljs only) file - but this doesn't work either.

I have tried using a workaround where the reader function returns a form, see https://github.com/henryw374/time-literals/blob/master/src/time_literals/data_readers.cljc and this works ok, except that now those reader functions don't work when being used with clojure (e.g. clojure.core/read-string) - see https://github.com/henryw374/time-literals/issues/3

Thanks,
Henry

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.