The user-provided examples and comments at ClojureDocs.org are not official Clojure documentation, but in many cases contain useful additional info.
I have just added examples to clojure.core/pr similar to those that motivated this thread, and Timothy Baldridge's suggestion to use transit in cases where such Clojure data may be present. http://clojuredocs.org/clojure.core/pr http://clojuredocs.org/clojure.edn/read Andy On Fri, Aug 5, 2016 at 6:42 PM, Blake Miller <blak3mil...@gmail.com> wrote: > I agree with Herwig in principal ... even though EDN is not meant to cover > the whole set of possible pure Clojure data, if it can be made to cover > more (all other things being equal) that would be a Good Thing. > > I think it would be possible to fix these edge cases with reader macro > dispatches without breaking compatibility. The major snag though is > that performance would suffer ... every single keyword or symbol being > `pr`d would have to be tested, even those in the vast majority that don't > need to be emitted in any special way. So my conclusion is it's not worth > trying ... > > It sucks that the docstring for pr https://github.com/clojure/ > clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L3552-L3555 fails to > mention that the function may succeed and produce a string that the reader > will barf on, but I think we're pretty much stuck with it. > > For posterity: I switched to using Transit for the Clojure(Script) app > that had me run across this issue. > > On Thu, Aug 4, 2016 at 2:23 PM, Herwig Hochleitner <hhochleit...@gmail.com > > wrote: > >> 2016-08-04 13:56 GMT+02:00 Timothy Baldridge <tbaldri...@gmail.com>: >> >>> The problem is that many do not understand that Clojure data is a >>> superset of EDN. The two were never meant to be completely compatible. >>> There are many things, especially when dealing with keywords and symbols, >>> where its possible to have data that doesn't properly round-trip. >>> >> >> Then fressian and transit are supersets of edn as well. Are those, at >> least, meant to be the same set as clojure data? >> Also, reader tags are a fantastic opportunity to make arbitrary data >> round-trippable. >> >> An added problem when dealing with EDN is that there is only really one >>> or two languages that properly parse it: Clojure and Clojurescript. So it's >>> also a poor choice to use in cases where you desire any sort of interop. >>> >> >> There many edn libraries for various languages: https://github.com/ >> edn-format/edn/wiki/Implementations >> It is true, that there is a lack of compatibility, especially in the >> handling of symbols and keywords and the community is hurting for it (I >> remember a couple of tedious discussions on the matter) >> >> see http://dev.clojure.org/jira/browse/CLJ-1527 https://gith >> ub.com/edn-format/edn/issues/67 ... >> >> Add on top of all that that EDN parsing is really slow compared to other >>> approaches, and you have a lot of compelling reasons to, as Herwig put it, >>> "abandon edn, except for hand-written data". >>> >> >> My view is, that those reasons should be eliminated, starting with >> interoperability concerns. I still think edn is a fantastic idea and to me >> it still holds the promise of being a replacement for json and xml, but >> only if we can get our act together and develop it towards that goal. >> >> Please note, that my "except for hand-written data" was meant to be >> hyperbole. Every data is eventually machine-written. >> >> Abandoning edn would send a fatal signal not just to people in the >> community. Especially if we let it slowly die instead of declaring it a >> failed experiment in data exchange. >> >> Imagine if pr wouldn't handle embedded " quotes in strings and the >> inofficial recommendation would be to just avoid that use case or use a >> different encoding. >> >> And yes, the original problem that caused the creation of Transit was >>> "how do we get data from language A to language B while still staying fast, >>> not implementing a ton of code, and keeping rich data (dates should be >>> dates, not strings)." >>> >> >> I like the idea of having various encodings for different uses, but we >> should strife towards compatibility. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/clojure/Rc_b4_Da-KU/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
