Email list hosting service & mailing list manager

Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (10 Dec 2021 07:26 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Jakub T. Jankiewicz (10 Dec 2021 10:20 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (10 Dec 2021 13:02 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (10 Dec 2021 13:07 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (10 Dec 2021 22:12 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Daphne Preston-Kendal (17 Feb 2022 13:17 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (17 Feb 2022 13:40 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Daphne Preston-Kendal (20 Feb 2022 08:25 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (20 Feb 2022 15:05 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (25 Feb 2022 07:29 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (25 Feb 2022 17:24 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (21 Feb 2022 18:10 UTC)
Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen (22 Feb 2022 08:13 UTC)

Re: NUL-terminated strings and eof-object-terminated generators Marc Nieper-Wißkirchen 22 Feb 2022 08:13 UTC

Am Mo., 21. Feb. 2022 um 18:54 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Sun, Feb 20, 2022 at 3:25 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:

[...]

>> Anyone who is seriously maintaining an implementation which isn’t willing to make major changes for the sake of Large support was alienated, at the latest, on Tuesday this week by the adoption of syntax-case. (I don’t see Chicken or MIT adopting more of Large now, for example.)

> That doesn't worry me.  There is going to be a section that explains variances from Small (e.g. the numeric tower), and one of the things it will say is that a partial implementation of Large is a Better Thing than a non-implementation.

While something instead of nothing is universally usually better, I
fear that such an attitude is detrimental to the R7RS-large project.
So far (and probably also finally), R7RS-large is basically a huge
collection of SRFIs. Now, if we endorse that implementations take
their pick of the parts of R7RS-large they intend to support (for
whatever reasons), we are basically in a pre-R7RS-large situation: A
huge corpus of SRFIs exists and portable code is possible under the
assumption that the target system implements the relevant SRFIs. If
this is going to be the de facto status of the implementation
landscape, the efforts we make here are out of proportion to what
R7RS-large would finally mean.

Note that we are not talking about shipping or not shipping some
non-central library like the Posix library SRFI 170 (which may not be
implementable in some systems for good reasons) but we are talking
about basic foundations like how the syntax expander works.