I addressed this here: http://news.ycombinator.com/item?id=4489330
On Sep 7, 2012, at 2:36 AM, Elliot wrote: > On Thursday, September 6, 2012 8:31:59 PM UTC-7, Weber, Martin S wrote: > The question that's left for me is: why vectors and lists? I mean, from a > data format perspective, and a non-clojure implementor, I'm not sure the > distinction makes sense. After all for the _data format_, in its serialized > form, the vector will not be a random access structure. It has to be > deserialized, and access to an element will have linear time complexity. > Again, I understand its relevance from the clojure perspective. Is this just > "too important" for edn's current "implementor", clojure ? > > a) This is just a feedback draft, and having both vectors and lists may not > be a grand commitment so much as a proposal. > > b) Every format will involve a tradeoff between how much is baked in as a > required primitive and how much is added via the extensibility mechanism, in > this case tags. Deciding whether to include both lists and vectors is just > adjusting the line between whether the edn library provider does more work > and the edn library user does less work, or vice versa. Again, it's just a > line in the sand and there will always be borderline cases of what different > people consider "must-have." > > c) Yes, if clojure and datomic use both lists and vectors frequently enough > and in different enough capacities, they can legitimately desire to have both > capabilities built into their interchange format, particularly if it makes it > concise and convenient to communicate with clojure/datomic (instead, for > example, of having to type `#list ()` all the time). It doesn't need to be a > universally minimalist generic format, and it _does_ need to be a format > simple enough for other languages/ecosystems to implement so that they can > communicate with clojure/datomic. These constraints seem sufficient to want > to push the edn decisions close to where they are in the proposal. Like most > other real world formats, there is a real use case that this one has in mind > even if it's not fully abstractly general. > > -- > 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 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
