Email list hosting service & mailing list manager

Tracking SRFI library names Lassi Kortela (13 May 2020 20:14 UTC)
Re: Tracking SRFI library names Lassi Kortela (13 May 2020 20:41 UTC)
Re: Tracking SRFI library names Lassi Kortela (13 May 2020 20:59 UTC)
Re: Tracking SRFI library names Lassi Kortela (13 May 2020 21:09 UTC)
Re: Tracking SRFI library names Arthur A. Gleckler (13 May 2020 21:56 UTC)
Re: Tracking SRFI library names John Cowan (14 May 2020 00:00 UTC)
Re: Tracking SRFI library names Lassi Kortela (14 May 2020 20:43 UTC)
Re: Tracking SRFI library names John Cowan (14 May 2020 21:01 UTC)
Re: Tracking SRFI library names Göran Weinholt (13 May 2020 22:20 UTC)
Re: Tracking SRFI library names Lassi Kortela (14 May 2020 20:38 UTC)
Re: Tracking SRFI library names Göran Weinholt (14 May 2020 21:14 UTC)
Re: Tracking SRFI library names Lassi Kortela (14 May 2020 21:37 UTC)
Re: Tracking SRFI library names Göran Weinholt (14 May 2020 21:44 UTC)
Re: Tracking SRFI library names Lassi Kortela (18 May 2020 08:13 UTC)

Re: Tracking SRFI library names Lassi Kortela 14 May 2020 20:42 UTC

> I think this is too convoluted.  Just keep a flat list of library names
> and don't worry about how long they are.

Name length is not the problem; it's that one SRFI can be exposed under
several library name prefixes. E.g. (srfi 1), (srfi :1), (srfi :1
lists), and (scheme list).

This is not usually such a problem, but for SRFIs with lots of
sublibraries like 160 there would be a four-fold repetition of all the
names.

> (srfi 146) and (srfi 146 hash)
> both exist, but (srfi 160) does not exist.  That allows us, for example,
> to add (scheme foo bar) to an existing (scheme foo) even though they
> happen to come from different SRFIs.

Yes. I mistakenly wrote (sublibraries () ...) in the SRFI 160 example.
It should be missing the ().