JSON Lines support Lassi Kortela (21 Jan 2020 12:05 UTC)
Re: JSON Lines support Amirouche Boubekki (21 Jan 2020 15:00 UTC)
Re: JSON Lines support Lassi Kortela (21 Jan 2020 22:47 UTC)
Re: JSON Lines support John Cowan (21 Jan 2020 22:51 UTC)
Re: JSON Lines support Lassi Kortela (21 Jan 2020 23:07 UTC)
Re: JSON Lines support John Cowan (22 Jan 2020 00:11 UTC)
Pretty-printing JSON Lassi Kortela (22 Jan 2020 00:22 UTC)
Re: Pretty-printing JSON John Cowan (22 Jan 2020 02:28 UTC)
Different kinds of JSON writers, and naming them Lassi Kortela (22 Jan 2020 11:52 UTC)
Re: Different kinds of JSON writers, and naming them John Cowan (22 Jan 2020 18:37 UTC)
Re: Different kinds of JSON writers, and naming them Lassi Kortela (22 Jan 2020 22:33 UTC)
Re: Different kinds of JSON writers, and naming them John Cowan (22 Jan 2020 22:44 UTC)
Re: Different kinds of JSON writers, and naming them Duy Nguyen (23 Jan 2020 10:01 UTC)
Optional features in SRFIs Lassi Kortela (24 Jan 2020 15:30 UTC)
Re: Optional features in SRFIs Lassi Kortela (24 Jan 2020 15:35 UTC)
Re: Optional features in SRFIs Arthur A. Gleckler (24 Jan 2020 15:57 UTC)
Re: Optional features in SRFIs John Cowan (24 Jan 2020 17:01 UTC)
Re: Optional features in SRFIs Lassi Kortela (24 Jan 2020 17:07 UTC)
(missing)
Re: Optional features in SRFIs Lassi Kortela (24 Jan 2020 18:43 UTC)
Re: Optional features in SRFIs Lassi Kortela (24 Jan 2020 17:12 UTC)

Re: JSON Lines support Lassi Kortela 21 Jan 2020 23:07 UTC

> A JSON writer that doesn't prettyprint by adding additional whitespace
> is automatically conforming to JSON Lines provided you call (newline
> port) afterwards.  Likewise, such a writer can be made to conform to
> JSON Sequence by calling (write-char #\x001E port) before and (newline
> port) after.

I've actually used JSON Lines to write logs from an application, and
having these concerns in mind is not enjoyable when you know your
production log will be corrupted in case you didn't remember to take
everything into account :) I'd rather call a standard procedure whose
name says it is guaranteed to conform. But maybe that's just my quirks.

> IMO prettyprinting should be done outboard anyway.
Not sure what you mean exactly, but in practice, being able to jot down
some data into a human-readable file by calling (write-pretty-json ...)
is really useful. Standard support for sorted keys is great for the same
reason, but it was covered in the other thread :)

In general, most JSON dumps are not big enough that the extra whitespace
or sorting are performance issues, and they can turn a human-unreadable
file into a readable one. Truly large JSON dumps are often compressed
with gzip or better anyway.

I'm not sure whether or not it's better for the default output to be
indented, but it's great if there's *some* easy-to-use procedure that
indents and sorts, even if it's a different one, as long as it's
standard. Pretty-printing options to the normal write procedure are also
fine IMHO. Getting the pretty-printing wrong is not stressful in the way
that writing potentially non-conforming data is.