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"Same behavior exists with keywords on both CLR and JVM, (edn/read-string ":foo/bar/baz") and (keyword "foo/bar/baz").
i believe this is known, but i can't find the jira ticket at the moment
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.
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