Thanks Richard. I didn't know that the spec was precise about the JSON
expr not going beyond the closing character. (I wasn't sure, for instance,
if it would also include whitespace after that point.)
For logging, I bet it helps if people try to enforce the invariant that
JSON text doesn't internally include newlines...
Best,
-Ryan
On Sun, May 29, 2016 at 10:25 PM, Richard A. O'Keefe
On 30/05/16 5:53 AM, Stephen Tetley wrote:
Hi Ryan
Isn't this a problem of JSON rather than it's parsers?
That's too say I believe (but could easily be wrong...) that a file with multiple JSON objects would be ill-formed; it would be well-formed if the multiple objects were in a single top-level array.
"A file with multiple JSON objects would be ill-formed" -- it would be an ill-formed *what*?
The media type application/json appears to describe a format containing precisely one JSON value, but RFC 7159 is otherwise silent about streams of JSON values.
JSON is sometimes used as the format for entries in logs; it would be pretty useless for that if you couldn't have more than one in a sequence.
If a JSON value is true, false, or null it ends at its last letter; if it's a string it ends at the closing double quote; if it's an array it ends at the closing ]; if it's an object it ends at the closing }; only if it is a number is there any need to check the next character, but then only one character needs to be checked, and thanks to the requirement that numbers be in ASCII, only one byte needs to be checked, there being no need to decode the next Unicode code point in full.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe