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 <ok@cs.otago.ac.nz> wrote:

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