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)
|
> 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.