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 Duy Nguyen 23 Jan 2020 10:01 UTC

On Wed, Jan 22, 2020 at 6:52 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > Having more procedures doesn't add complexity, but having more
> > *exported* procedures does.  Each one is another attack surface for
> > penetration testing, another bit of documentation, another  item to
> > master in order to master the API.  I have in general gone much further
> > in this direction, following Olin Shivers's SRFI 1, than many people
> > think I should have.
>
> While that is true, it's also an inherent property of successful
> general-purpose languages that they do a lot, and do it conveniently.
> The long-term trend is toward all software converging into one system
> (we just can't agree on whose system that should be).
>
> I'm in favor of your and Olin's comprehensive approach for libraries and
> it pushed my own thinking more in that direction. I don't always see the
> point of a particular procedure in a SRFI, but if it's logically
> specified (and they generally are) I give it the benefit of the doubt.
>
> I also think there's a point to having a mix of minimalist SRFIs and
> maximalist SRFIs (maximalism is a word in some circles).

With library support in r6rs and r7rs we could even have the best of
both worlds: have core procedures in (srfi N) and convenient/utility
stuff in (srfi N extra) or something. Scheme implementors could choose
to support just (srfi N) if they prefer minimalism.
--
Duy