Email list hosting service & mailing list manager

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: Different kinds of JSON writers, and naming them Lassi Kortela 22 Jan 2020 22:33 UTC

> I think it would be a mistake for the SRFI to prescribe some
> particular pp algorithm, though.

Agreed. That sounds too complex. Unless Amirouche wants it, since it's
his SRFI.

>     ability to put JSON keys in a convenient application-specific order.
>
> I see what you mean, but we don't have a good mechanism for creating
> such ordering predicates.  The enum machinery I have a pre-SRFI for will
> allow it:  an enum object has a distinct type and four instance
> variables: the enum type, the symbol name, the ordinal number, and the
> arbitrary value.

https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/EnumsCowan.md

Would it work to just accept a (less? key1 key2) predicate? Maybe the
enum SRFI can provide a predicate-maker.

> I think json-write would make the most sense here.  Scheme doesn't have
> a standard name for write-then-newline like writeln in many languages or
> CL print.

Racket has `writeln` and `displayln`. Both are so useful, I wish they
were standard.

> That's why I think json-write and json-write-sequence-text are best.

Hmm. I feel there's something missing with all the alternatives we've
thought of so far. I wish someone thought of an unexpected solution :)

Amirouche, do you have an opinion?

>     Finally, one could add a `json-pretty-write` or `json-pretty-print` (or
>     `json-indented-write` or `json-custom-write`, etc.)
>
> I like json-pp for analogy with pp.

Not bad! That didn't occur to me.

> pp should not be called pretty-print, because it is a case in which terseness
> is actually important.

Fair enough.

> We could just say that json-pp is the same as json-write,
> but may introduce additional whitespace for better human readability.
> That allows a minimal implementation where memory is tight to make it
> the same as json-write.

json-pp should probably allow a custom indent string (N spaces or a tab)
since people will probably want to write files that conform to the style
used in some existing collection of JSON files.