
That's pedantic and beside the point. The question is not what JSON supports, but rather how to best represent data which consists of ordered key-value pairs using JSON. I'll second the solution of [{"key1": "value"}, {"key2": "value"}]. Richard A. O'Keefe writes:
On 16/12/2014, at 9:39 pm, Tobias Dammers
wrote: No, that's not what I meant. By "ordered", I meant that the in-memory representation of the document should maintain file order.
You did consult RFC 4627, right?
Page 1: "An object is an UNORDERED collection of zero or more name/value pairs”.
Or www.json.org?
Just above the railroad diagram for objects, “An object is an UNORDERED SET of name/value pairs.”
Or RFC 7159? Section 1: “An object is an UNORDERED collection of zero or more name/value pairs”. The new thing in RFC 7159 is "JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.”
That is, the file order is WITHOUT SIGNIFICANCE. If you happen to use a library that preserves that order in memory, NOTHING SHOULD DEPEND ON THAT if you want your software to be interoperable.
Recall that JSON is explicitly derived from Javascript and that a JSON “object” is explicitly (www.json.org) "an object, record, struct, dictionary, hash table, keyed list, or associative array” so that the *intended* in-memory representation for a JSON object is an *unordered* data structure.
So if you depend on the order of the name/value pairs in a JSON object, you doing something surpassing strange and risky.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Kyle Marek-Spartz