Fork me on GitHub

👋 has been on 0.2.0-alpha6 for over 2 years, with the latest stable being 0.0.8, yet is itself stable and with 0.0.8 and requires 0.2.0-alpha6 instead. Is there anything preventing the rollout of a 1.0 version of org.clojure/data.xml @alexmiller?

👍 3
Alex Miller (Clojure team)14:12:01

To be honest, I don’t know. data.xml is run by Herwig. I’ve asked him this question a couple times and have not gotten an answer. It was originally alpha because of the namespace mapping approach I believe. I can certainly ask again :)


:thinking_face: Actually there’s a rather big breaking change between the 2 versions as isn’t there anymore in 0.1.0 as it’s been moved to Since we’re using both cognitect/aws-api and circleci.tests (, I’m kinda stuck 😢. I’ll have to move away from circleci.test I reckon.

Alex Miller (Clojure team)15:12:16

I have not looked at that. doing a quick skim, seems like users of data.xml are pretty split on 0.0.x and 0.2.0-alphaY


Even the default behaviour of in both versions is different. They should be different libraries at that point so that both could coexist.

clj -Sdeps '{:deps {org.clojure/data.xml {:mvn/version "0.0.8"}}}'
Clojure 1.10.1
user=> (require '[])
user=>  ( "<tag1>\n  <tag2>bar</tag2>\n</tag1>"){:tag :tag1, :attrs {}, :content ({:tag :tag2, :attrs {}, :content ("bar")})}
clj -Sdeps '{:deps {org.clojure/data.xml {:mvn/version "0.2.0-alpha6"}}}'
Clojure 1.10.1
user=> (require '[])
user=> ( "<tag1>\n  <tag2>bar</tag2>\n</tag1>")
#xml/element{:tag :tag1, :content ["\n  " #xml/element{:tag :tag2, :content ["bar"]} "\n"]}

Jakub Holý (HolyJak)12:12:19

Hello! How can I require a namespace with unknown tagged literal (`#uknown-tagged-literal` in this case)? I have tried

(binding [*default-data-reader-fn* (fn [tag value] nil)]
      (require namespace))
expecting the data to simply become nil but the only effect is that the former exception, > ExceptionInfo: /path/to/unknown_tagged_literal.cljc [line 4, col 38] No reader function for tag uknown-tagged-literal. has been replaced with > Caused by: clojure.lang.Compiler$CompilerException: Syntax error reading source at (metagetta_test_special/unknown_tagged_literal.cljc:4:41). > Caused by: java.lang.RuntimeException: No dispatch macro for: u >  at clojure.lang.Util.runtimeException ( >   clojure.lang.LispReader$DispatchReader.invoke ( > ( >   clojure.lang.LispReader.readDelimitedList ( >   clojure.lang.LispReader$ListReader.invoke ( > ( > ( >   clojure.lang.Compiler.load ( For more details you can see the code at and the errors in the commit message here 🙏 (My intention is to allow #cljdoc to read sources even if they contain unknown tagged literals; it only cares about top-level publics so it should not matter most of the time.)


@holyjak you can use tagged-literal

❤️ 3
Jakub Holý (HolyJak)14:12:22

Thanks a lot, that fixed it! I guess my problem was that my *default-data-reader-fn* returned nil , perhaps it must return something non-nil not to fail downstream.

Jakub Holý (HolyJak)14:12:22

Thanks a lot, that fixed it! I guess my problem was that my *default-data-reader-fn* returned nil , perhaps it must return something non-nil not to fail downstream.

Yehonathan Sharvit15:12:11

Hello! Are there any forbidden characters inside a keyword? I tried to convert a string with special chars and hebrew chars and I couldn’t make the keyword function fails

(keyword "aa/bbשלום/dd.dd/a:::$$$ :a")

Alex Miller (Clojure team)16:12:46

officially, from the reader reference the allowed set is "alphanumeric characters and *, +, !, -, _, ', ?, <, > and =". Hebrew chars would imo fall under "alphanumeric". / and : have special constraints that are further elaborated on in the text.

Yehonathan Sharvit11:12:04

Thank you for the detailed clarification


yes, the reader has some rules ( but it's not all enforced, but you'll get broken behavior if you do not respect them in some cases


(keyword "")


they will be unreadable essentially


(keyword "" "")
=> :/


it can get weird fast

Yehonathan Sharvit16:12:14

I have no intended plan to break the rules but I am willing to use for retrieving value on HBase. cbass find-by functions automatically keywordize column names. I am asking myself if it could break in some edge cases

Alex Miller (Clojure team)16:12:12

programmatically created keyword objects are fine and useful for things like these - you get into trouble when you venture into print/read roundtripping

Alex Miller (Clojure team)16:12:36

if that's a thing you expect to do, you should use strings instead

Yehonathan Sharvit16:12:01

Thanks for the clarification

Yehonathan Sharvit16:12:28

So basically any string could be programmatically converted to a keyword?


You can test this using clojure.spec.gen.alpha :)


If I'm not mistaken, a keyword is interned using a symbol and that in turn is represented by strings internally: So I think it should work for all strings.


some time ago I saw on youtube someone using an emacs setup to step into a function so that the result of each form was printed as he went along (for debugging). Do you know what that could have been?


Maybe the cider debugger?


yes, that was probably it, although it doesn't seem to work with clojurescript is there an alternative for clojurescript?


i'm not aware of any debugger for cljs. Cursive and CIDER each only support Clojure as far as I am aware


It is editor agnostic.

🙌 3