It just crossed my mind, in our latest product version, we have protocols extending lists, vectors and maps. I would hate very much to see lists converted to vectors because the spec does not support forwarding lists.
The receiver would not be able to act on the decoded structure properly with this scenario. Ok, protocols are Clojure specific but this illustrates a subtle difference between sequential access versus random access that needs to be conveyed somehow. Is this too Clojure specific ? Maybe for the near future, what about in 5 years ? Want to consult Mrs Irma and her crystal ball to get an answer ? Luc P. > You may want to distinguish between sequential versus random access, > if your language supports both. > > If there is no such need in a given language, then the implementation can > parse them > to the same data structure. > > Why not meet the general case ? What's the cost ? You are not doing this > processing > by hand :) > > The too frequent problem in all these tools (XML, YAML, JSON, ...) is to have > designed them with a narrow scope from the start. We ended up with an array > of tools > with each having flaws because every opened door was closed with statements > like > "we will never need this, we cannot foresee why we would like to do this, > ...". > > Having data as the main scope may be too narrow. > > If I send a custom literal that will eventually is turned into a factory call, > I am sending more than just data. I may send stuff that alter the behavior if > the > factory fn is this good design ? Maybe yes, maybe not. But who are we to > judge ? > > Let's keep Rich think out of the box instead of trying to restrict him to > the same sandbox as the other tools above. > > Luc P. > > > (sorry for top-posting) > > > > Languages have random access / sequential data structures. > > > > Sure. Languages. This is a data format, not a language. Why should I not > > inflate a edn-list into a vector in my language? What if I don't have a > > random access thing handy (because, e.g., I only have trees/tables, as e.g. > > tcl where arrays are actually hashtables with integer keys)? Please do read > > my post again. I'm aware of the clojure link etc. etc. etc. We're talking > > about a data format here. > > > > Regards, > > -Martin > > > > ________________________________________ > > From: clojure@googlegroups.com [clojure@googlegroups.com] On Behalf Of Sean > > Corfield [seancorfi...@gmail.com] > > Sentd: Friday, September 07, 2012 18:44 > > To: clojure@googlegroups.com > > Subject: Re: edn > > > > On Thu, Sep 6, 2012 at 8:26 PM, Weber, Martin S <martin.we...@nist.gov> > > 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 ? > > > > I think it's a useful hint to allow sequences of data that can be > > inflated into data structures supporting random access in constant > > time vs those that don't. Many languages have both list-like > > collections AND array-like collections. > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View -- http://corfield.org/ > > World Singles, LLC. -- http://worldsingles.com/ > > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > > 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 > > > -- > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! > > -- > 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 > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- 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
