[GreaterFool]

It's a little bit more than just a cute intellectual puzzle. One could build an efficient EDN library based on that or very similar type. See Haskell's JSON library:

https://github.com/bos/aeson/blob/master/Data/Aeson/Types/In...

> though the Clojure expressions are a little leaner

Yes they are. The price is complete lack of type safety. And the benefit is an insignificantly small reduction in boilerplate code.

The number of bugs I've seen where somebody would "get" a number that turned out to be a string or string that turned out to be a number...

[dustingetz]

EDN is not JSON. EDN is Extensible. OP has everyone in this thread arguing about a strawman.

[tome]

Then I think you're really going to need to educate us about what EDN really is ...

[escherize]

Educate yourselves. https://github.com/edn-format/edn/blob/master/README.md#tagg...

[tome]

> edn supports extensibility through a simple mechanism. # followed immediately by a symbol starting with an alphabetic character indicates that that symbol is a tag

OK, so it's trivial to add that as a constructor to the Haskell EDN type in the post, and you can even support it in JSON with a dictionary like

    #myapp/Person {:first "Fred" :last "Mertz"}

is represented as

    {"#myapp/Person" : { "first" : "Fred", "last" : "Mertz" } }

What are the remaining objections?

[dustingetz]

EDN is much more like XML than it is JSON.

1) When I read #uri "http://google.com" my app code sees (java.net.URI. "http://google.com"), not Tag "URI" "http://google.com" or whatever. clojure.core/map does not see tagged values, it does not know that the values were ever read from edn.

2) Extension happens in userland library code, you don't need to go modify the hardcoded pattern match in core. (Talking about reifying actual instances that we can code to, not reader tags)

3) Data is just information. Information isn't coupled to code, it's abstract values, totally separate from the concrete implementation. As RH says: "code is data. But data is not code until you define a language around it." Typeclasses are about code.

4) EDN values are cross platform and a platform's EDN reader can reify the value into an idiomatic type for that platform. E.g. a haskell edn reader could reify #error "foo" into Left String; a Java reader a Throwable to be re-thrown later.

5) The whole prism diversion is sophomoric. Once you've read the EDN into concrete values of whatever platform type, you can use whatever platform abstractions you like to manipulate them. Clojure has lenses too: http://funcool.github.io/lentes/latest/#composition

You can watch the EDN talk or read the transcript if you'd like to learn more. This topic is very deep but this thread is not doing it justice.

[tome]

I think it would be a great service if someone would write up a technical introduction to this for non-Clojurists. You seem to be communicating a subtle point that not many of us are getting ...