On Sep 10, 2012, at 8:44 AM, Ben Smith-Mannschott wrote: > On Mon, Sep 10, 2012 at 2:15 PM, Marko Topolnik > <marko.topol...@gmail.com> wrote: >>> Java has arrays, lists, maps and sets, so does Ruby and Erlang. >>> >>> If they were redundancies in these structures, can't see why these three >>> still >>> maintain this distinction. It's probably a safe bet to say that we need to >>> convey these >>> nuances in edn somehow. >> >> >> Let's keep this in perspective: this is not about conveying and not >> conveying. If edn had only vectors, the nuance could still be conveyed >> through a tag. This is ONLY about what gets baked in and what is left over >> to extensions. >> >> Take a similar example from Java: there are no list/set/map literals in it. >> Sure, you can write an API call that mimics it, but it's nowhere near as >> convenient as a native construct. So, do we want edn to support the >> list/vector distinction only through extensions? Have our data files riddled >> with #list annotations? This is a strong argument in favor of the feature >> from the Clojure folks' perspective, while on the opposite side we have a >> quite weak motivation to make the format a tiny bit simpler to parse. > > Having written (most of) a recursive decent parser for edn over the > weekend, I submit that the difference in complexity introduced by > supporting both [ ] and ( ) as opposed to supporting only one of them > is not worth worrying about. > > // Ben
Thanks for that data point. Just to be perfectly clear to everyone - this aspect of edn is not going to change, whatever your opinions, so now might be a good time to let this argument rest. Rich -- 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
