Clojure Q&A - Recent questions tagged edn

Namespaced map conversion fails when namespace keyword starts with a number

Mon, 06 Jul 2026 15:16:32 +0000

It looks like Clojure has no problem with either :0 or :0/a, but when used together in a namesapced map it fails during some internal conversion.

Worst part: it prints back an unreadable form when if I feed it {:0/a :val}

user=> :0
:0
user=> :0/a
:0/a
user=> {:0/a :val}
#:0{:a :val}
user=> #:0{:a :val}
Syntax error reading source at (REPL:45:5).
Namespaced map must specify a valid namespace: 0
:a
:val
Syntax error reading source at (REPL:45:13).
Unmatched delimiter: }

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

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?

clojure.edn parser will not parse complete file in some cases

Wed, 07 May 2025 12:29:34 +0000

I've noticed that clojure.edn parser will skip rest of the file if it manages to find the first valid token that will complete collection. For example:

;; demo.edn
{
 :foo 1
 :bar 2 }
 :baz 3 
}

with:

(require '[clojure.edn :as edn]
         '[clojure.java.io :as io])

(with-open [r (io/reader "demo.edn")]
  (edn/read (java.io.PushbackReader. r)))

user=> {:foo 1, :bar 2}

It will also ignore rest of the file when the file is clearly malformed:

{
 :foo 1
 :bar 2 }
xxxx yyyy }}}}} {{{{ ((
 :baz 3

it returns again:

user=> {:foo 1, :bar 2}

I was expecting it to throw EOF exception or at least '}' mismatch. Is this behavior by design or a possible bug?

How to persist Clojure data structures to disk?

Tue, 22 Oct 2024 08:45:52 +0000

Hello,
I'm building a web crawler in Clojure that records its results in a map of maps. The data structure basically looks like this:

{"https://example.org" {:base-url "https://example.org"
                        :crawled {"/blog" {:relevant true :status 200}
                                  "/contact" {:relevant false :status 200}}
 "https://foo.com" {:base-url "https://foo.com"
                    :crawled {"/home" {:relevant true :status 200}}}

The web crawler is feed with a list of websites. However, for the sake of efficiency I want to avoid crawling already crawled websites. Therefore, I was looking for a way to persist the above data structure so that it can be consulted in subsequent runs to check if a given website was already crawled. (Of course, I have other reasons to store the results too, e.g. to do various analysis on the captured data)

First, I thought EDN would be a perfect solution. To my surprise, clojure.edn does not have write functions. A lot of advice online says to use pr-str. However, using pr-str has caveats as pointed out in https://nitor.com/en/articles/pitfalls-and-bumps-clojures-extensible-data-notation-edn (e.g. possbile truncations when print-length is set). And it's totally possible to generate invalid edn as pointed out in this comment by @alexmiller: https://ask.clojure.org/index.php/10278/should-pr-str-on-a-function-produce-valid-edn-syntax?show=10282#c10282.

Despite https://clojuredocs.org/clojure.edn claiming that it is "designed to be used in a similar way to JSON or XML" I have the impression it is more geared towards writing edn files by hand (i.e. configuration files).

Looking for alternatives, I stumbled upon Transit. However, its mainly intended "as a wire protocol for transferring data between applications". And the README further says

If storing Transit data durably, readers and writers are expected to use the same version of Transit and you are responsible for migrating/transforming/re-storing that data when and if the transit format changes.

Because in Clojure, data is code and code is data and because of the existence of EDN, I really thought persisting simple data structures like the above would be a breeze in Clojure.

Instead I see these sub-optimal options with my current knowledge:

Hope that pr-str produces valid EDN without loss in my particular case
Build a custom XML serialization
Use Transit
Use JSON?! (what about keywords etc.?!)

Is there a more idiomatic way to store and read back in simple Clojure data structures?

Is edn-format.org supposed to be online?

Wed, 18 Sep 2024 09:29:07 +0000

The documentation of clojure.edn/read references http://edn-format.org. However, it is offline.

A Whois query results in name servers like ns1170.dns.dyn.com. When doing the dig query dig @dns.google.com edn-format.org NS, I got "Network Error" messages.

Maybe https://github.com/edn-format/edn is supposed to replace edn-format.org. In this case, updating the api reference would be good.

In addition, https://clojuredocs.org/clojure.edn references edn-format.org as well.

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?

How to store Hiccup HTML structures in EDN files?

Sat, 17 Dec 2022 18:50:52 +0000

I want to store blog posts in EDN file like the one shown below and then convert them to HTML.

Here is a sample file:

    {:slug "slug"
 :title "The first blog post"
 :body [[:div
         [:p "First paragraph"]
         [:ul

          [:li "List Item 1"]
          [:li "List Item 2"]
          [:li "List Item 3"]]

         [:p "Second paragraph"]]]}

Then I try to read it using the following code:

(ns cl-www.core
  (:use [hiccup.core])
  (:require [cl-www.logic :refer [render-everything]]
            [cl-www.common :refer [prettify-html]]
            [clojure.edn]
            [clojure.java.io])
  (:import (org.jsoup Jsoup)
           (org.jsoup.nodes Document))
  (:gen-class))

(def path "/Users/myuser/cl-www/resources/p-2022-12-17.edn")

(defn test-edn
  []
  (let [post-data (-> path
                      (slurp)
                      (read-string))
        post-struct (:body post-data)
        html-struct [:html
                     [:body
                      [:h1 "Hello"]
                      post-struct]]

        html (->> html-struct
                  (html)
                  (prettify-html))]

    (println html)))

When I run (test-edn) I get the following error:
Execution error (IllegalArgumentException) at hiccup.compiler/normalize-element (compiler.clj:59). [:div [:p "First paragraph"] [:ul [:li "List Item 1"] [:li "List Item 2"] [:li "List Item 3"]] [:p "Second paragraph"]] is not a valid element name.
How can I fix it, i. e.

manually write a EDN file, then
read it in Clojure,
insert into a Hiccup structure, and
export it to HTML?

Programmatically connect dependencies to the maven repos that provide them

Fri, 11 Nov 2022 20:38:29 +0000

As a Clojure developer,
I want to be able to link project dependencies to the maven repos that provide them
so that a) tools that work with dependencies (e.g. nvd-clojure, clj-watson) have more first-hand information to work with, b) I can easily find out custom maven repos that are no longer used and c) get a better understanding in general of what my project is composed of.

Workaround

clj -Sdeps '{:mvn/local-repo "tmp"}' -Stree uses a custom local maven repo to force a redownload of the jars and provides a way to do the above by looking at the messages (e.g. Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.pom from central), so it can be ok in some cases.

Would you consider simplifying this process by providing a way to get that information as data? I would love to have it in clj -X:deps tree :format :edn for instance.

Adding support for byte sequences to the EDN standard

Tue, 07 Sep 2021 23:30:50 +0000

How do I get support for byte sequences to EDN? One implementation might be from adopting the mechanism used by Bencode: https://wiki.theory.org/index.php/BitTorrentSpecification#Bencoding

This still requires some context and doesn't allow for top level direct arbitrary binary to be accepted as valid. I'm not sure this is the best method, but I do need some way to represent arbitrary binary blobs well. One thing to also consider is interrupted data, which bencode's approach does not work well with. That might always be an application level concern, I'm not sure.

How do I effectively use EDN with C/C++?

Tue, 07 Sep 2021 01:55:21 +0000

Hello, I'm very new to Clojure related technologies and I may be asking the wrong question.

I am looking into making a IPFS like proof of concept using EDN which can be integrated with classical system languages (namely the old duo of C/C++). I would like to create an interface for C++ that takes a template data structure from compile time and from a filename create and populate a data structure matching that template. In C, it would be some ugly thing with structs composed of an enum to indicate the current primitive (either a list, set, or bytes), a void pointer, and all that C hackiness. Then from these, similarly have serializes.

The reason for EDN in particular is that it appears to be a technically superior specification based on it's foundations. The lack of need for a top level containing data structure, and extensible types look like a very good foundation for any work. It looks like EDN is missing the same level of support as formats like JSON. That makes this tough, but I think I can justify contributing something here. I am looking for a solution that can be reused at some point as a part of a Linux kernel module for embedding this functionality as a file system, but that's a ways off.

How do I start on this kind of project? What details am I missing?

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.

No metadata on clojure 1.9 map literals

Wed, 23 Jun 2021 07:40:15 +0000

Maps written using the new #:default.namespace{,,,} syntax don't get file positions attached as metadata.

Given this setup code

(require '[clojure.tools.reader :as reader])
(require '[clojure.tools.reader.reader-types :as reader-types])

(defn sample [s]
  (with-open [r (java.io.StringReader. s)]
    (meta (reader/read (reader-types/indexing-push-back-reader (reader-types/push-back-reader r) 1)))))

this edn literal fails to get parsed with positional metadata

(sample "#:ns{ :key :val }") ; => nil

unlike those two, which get their positional metadata as expected

(sample "{ :key :val }")     ; => {:line 1, :column 1, :end-line 1, :end-column 14}
(sample "{ :ns/key val }")   ; => {:line 1, :column 1, :end-line 1, :end-column 16}

Looking for a safe way to read EDN with file position metadata

Wed, 23 Jun 2021 07:32:57 +0000

I'm parsing untrusted data. To improve error reporting, I'd like to keep track of file positions.

As far as I can tell, clojure.tools.reader.edn/read is the correct tool for untrusted data, but it doesn't do file position metadata, whereas clojure.tools.reader/read has the file position metadata, but it can end up running code on behalf of the untrusted data, which is obviously not ideal.

If I bind data-readers to a map of know-safe readers, and read-eval to false, would that still leave me open to unwanted code execution by the untrusted data, or would it make clojure.tools.reader/read safe to use on my EDN?

What's up with this difference between reading UUIDs in edn between clj and cljs?

Mon, 26 Apr 2021 16:43:57 +0000

Hello! As ever, super-grateful for cljs - it's a huge multiplier on our efforts and we continue to love it as we use it all day long every day.

After upgrading clojurescript versions, we started getting a strange read-string related error: "No reader function for tag uuid."

cljs repl:

ClojureScript 1.10.238
app:cljs.user=> (cljs.tools.reader.edn/read-string "#uuid \"eed86fd1-4110-44d8-8f41-27473029cc6a\"")
#error {:message "No reader function for tag uuid.", :data {:type :reader-exception, :ex-kind :reader-error}}
   new (jar:file:/home/harold/.m2/repository/org/clojure/clojurescript/1.10.238/clojurescript-1.10.238.jar!/cljs/core.cljs:11123:11)
   Function.cljs$core$IFn$_invoke$arity$3 (jar:file:/home/harold/.m2/repository/org/clojure/clojurescript/1.10.238/clojurescript-1.10.238.jar!/cljs/core.cljs:11155:5)
   Function.cljs$core$IFn$_invoke$arity$2 (jar:file:/home/harold/.m2/repository/org/clojure/clojurescript/1.10.238/clojurescript-1.10.238.jar!/cljs/core.cljs:11153:16)
   cljs.core/ex-info (jar:file:/home/harold/.m2/repository/org/clojure/clojurescript/1.10.238/clojurescript-1.10.238.jar!/cljs/core.cljs:11150:1)
   Function.cljs$core$IFn$_invoke$arity$variadic (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/impl/errors.cljs:37:13)
   cljs.tools.reader.impl.errors/throw-ex (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/impl/errors.cljs:26:1)
   Function.cljs$core$IFn$_invoke$arity$variadic (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/impl/errors.cljs:43:4)
   cljs.tools.reader.impl.errors/reader-error (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/impl/errors.cljs:39:1)
   cljs.tools.reader.impl.errors/throw-unknown-reader-tag (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/impl/errors.cljs:221:4)
   cljs$tools$reader$edn$read_tagged (jar:file:/home/harold/.m2/repository/org/clojure/tools.reader/1.3.3/tools.reader-1.3.3.jar!/cljs/tools/reader/edn.cljs:372:10)

app:cljs.user=> (cljs.tools.reader.edn/read-string {:readers {'uuid uuid}} "#uuid \"eed86fd1-4110-44d8-8f41-27473029cc6a\"")
#uuid "eed86fd1-4110-44d8-8f41-27473029cc6a"

clj repl:

> (clojure.edn/read-string "#uuid \"eed86fd1-4110-44d8-8f41-27473029cc6a\"")
#uuid "eed86fd1-4110-44d8-8f41-27473029cc6a"

Previously, reading edn behaved more similarly between cljs and clj. I found the workaround of passing the map as the first argument by looking at the tests in tools.reader.

Is this expected?

Thanks for your time and consideration.

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.

Exhaustive spec checking like spec/keys, how?

Tue, 26 May 2020 17:59:15 +0000

My understanding is that spec/keys works for validating specific keys in a hash-map. However, I need it to also reject a hash-map that contains keys that are not in :req and :opt.

For a contrived example, imagine I have a definition of a person as an edn:

{:name "John"
:age 25}

The spec could be:

(spec/def ::name string?)
(spec/def ::age int?)
(spec/def ::person (spec/keys :req-un [::name ::age]))

The above definition would conform to this ::person spec.

However, let's say that, due to a confusion by a developer, another key unrelated to a Person's definition was added, and the hash-map is now:

{:name "John"
:age 25
:voltage 220}

That would still conform to the spec. But I want it to fail!

Is there a simple way to make spec/keys reject a hash-map that has keys that are neither req nor opt?

Programatically modifying an edn file that uses data reader functions

Wed, 29 Apr 2020 15:49:47 +0000

Say I have an edn file like this:

{:name :some-name
:some-key #my/data-reader-fn [1 2 3]}

Now say I want to change the content of :name programatically.

If I read the edn file, the data-reader-fn will be applied, and so if I want to write my changes to the edn file, :some-key will be changed too.

Is there a workaround for this problem?

is there a version of pr-str that emit full versions of qualified keywords in maps instead of short forms?

Fri, 10 Apr 2020 07:54:25 +0000

Something like {:foo/bar 1} instead of #:foo{:bar 1}
I need to debug some edn and it's impossible to jump to the desired keywords if they're in the short forms.