[Haskell-cafe] JSON parser that returns the rest of the string that was not used
rrnewton at gmail.com
Mon May 30 13:16:42 UTC 2016
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...
On Sun, May 29, 2016 at 10:25 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz>
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe