|
SRFI 228 final read-through
Arthur A. Gleckler
(10 Dec 2022 18:44 UTC)
|
|
Re: SRFI 228 final read-through
Daphne Preston-Kendal
(10 Dec 2022 18:49 UTC)
|
|
Re: SRFI 228 final read-through
Arthur A. Gleckler
(10 Dec 2022 18:55 UTC)
|
|
Re: SRFI 228 final read-through
Lassi Kortela
(10 Dec 2022 20:43 UTC)
|
|
Re: SRFI 228 final read-through
Lassi Kortela
(10 Dec 2022 20:46 UTC)
|
|
Re: SRFI 228 final read-through
Marc Nieper-Wißkirchen
(10 Dec 2022 20:49 UTC)
|
|
Re: SRFI 228 final read-through
Lassi Kortela
(10 Dec 2022 20:56 UTC)
|
|
Re: SRFI 228 final read-through Daphne Preston-Kendal (10 Dec 2022 20:57 UTC)
|
|
Re: SRFI 228 final read-through
Lassi Kortela
(10 Dec 2022 21:46 UTC)
|
|
Re: SRFI 228 final read-through
Daphne Preston-Kendal
(10 Dec 2022 22:09 UTC)
|
|
Re: SRFI 228 final read-through
Lassi Kortela
(10 Dec 2022 22:27 UTC)
|
|
Re: SRFI 228 final read-through
John Cowan
(10 Dec 2022 21:29 UTC)
|
|
Re: SRFI 228 final read-through
Arthur A. Gleckler
(10 Dec 2022 22:03 UTC)
|
|
Re: SRFI 228 final read-through
Daphne Preston-Kendal
(10 Dec 2022 22:12 UTC)
|
|
Re: SRFI 228 final read-through
Arthur A. Gleckler
(11 Dec 2022 02:54 UTC)
|
On 10 Dec 2022, at 21:56, Lassi Kortela <xxxxxx@lassi.io> wrote: > It's confusing if an SRFI exports identifiers that are not defined in the text of some other SRFI. > > I sympathize with the desire to have more convenient libraries to import, instead of importing a whole bundle of SRFIs. But this is IMHO a misuse of the SRFI process. This is yet another problem that comes back to the basic fact that SRFI is not good at addressing evolving needs. I strongly disagree and would like to politely request that you not use the mailing list for this SRFI to discuss your views on the issue of the SRFI process in general. Daphne
