2016-08-04 13:56 GMT+02:00 Timothy Baldridge <[email protected]>: > 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://github.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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
