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)

Optional features in SRFIs Lassi Kortela 24 Jan 2020 15:30 UTC

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

Arthur and John know best about this topic, but I got the impression
that SRFIs are not intended to have optional parts. If optional features
are desired, the custom is to put them in a separate SRFI which has a
dependency on the other SRFI containing the core procedures. Cross-SRFI
dependencies are fine when they serve a purpose, and there are many
existing examples of them.

There is no particular need to have as few SRFIs as possible, so making
another SRFI for optional JSON stuff is probably no problem at all. We'd
just have to think of a good feature set for it.

I've had a few ideas for a SRFI that would have one or two procedures,
but haven't dared submit them :) It seems too trivial. But if the
procedures are really important for some job, maybe it's not.