|
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)
|
Why can´t we simply specify that SRFI 228's library includes all exports from SRFI 128, 162, and those defined in the SRFI 228 spec? As a byproduct, this way, SRFI 228 can clean up the situation about SRFI 128/162. Am Sa., 10. Dez. 2022 um 21:46 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > NB: "rather than being in a separate library" is especially ambiguous; > does it suggest that if and when the procedures ship in some other > library, the (srfi 228) library should be retroactively removed from the > relevant Scheme implementations?
