clr

2026-06-16T15:49:16.554459Z

Probably no big deal (as this isn't exactly valid edn), but I noticed this while working with edn, so figured I'd ask. edn/read-string reads symbols differently than symbol, making (apparently) equivalent symbols not equal, I think because their namespace+name parses at different points. On the JVM, both edn/read-string and symbol parse with "foo" namespace and "bar/baz" name. Is this a gap that should be closed, or is this known/acceptable behavior?

=> (def edn-foo (edn/read-string "foo/bar/baz"))
=> (def sym-foo (symbol "foo/bar/baz"))
=> (= edn-foo sym-foo)
false
=> (namespace edn-foo)
"foo/bar"
=> (name edn-foo)
"baz"
=> (namespace sym-foo)
"foo"
=> (name sym-foo)
"bar/baz"

2026-06-16T15:57:05.937419Z

Same behavior exists with keywords on both CLR and JVM, (edn/read-string ":foo/bar/baz") and (keyword "foo/bar/baz").

2026-06-16T16:15:03.846899Z

i believe this is known, but i can't find the jira ticket at the moment

2026-06-16T16:17:00.427179Z

https://clojure.atlassian.net/browse/CLJ-1530

❤️ 1
2026-06-16T16:25:30.065679Z

Thanks! This is very insightful. > The 1-arity form will split based on the first / found (in this example into "foo" and "bar/baz"). I see no reason that would need to change. JVM splits on the first /, which tracks with what I'm seeing in the repl. For that reason, one could argue that other dialects should conform to this for consistency. But then again, Alex also wrote: > Your api is using illegal keywords according to http://clojure.org/reference/reader and you should not expect them to work. So I can also see an argument for it not really mattering what happens in these invalid edn cases.

2026-06-16T16:27:41.326249Z

yeah, it's a situation where clojure is optimized for "correct programs", so it doesn't check because it expects you to provide conforming inputs

👍 1