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 25 Feb 2022 17:23 UTC

(Added WG2.)

Am Fr., 25. Feb. 2022 um 18:09 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Feb 25, 2022 at 2:29 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>>
>> If it emerges that essential compatibility with R6RS is not possible
>> on technical grounds, this is one thing, but forbidding R6RS
>> compatibility on political grounds
>
>
> I didn't say they objected on political grounds; in fact, I don't know their reasons.  I said that if you wanted that judgment changed, you'd have to use political means.
>>
>> is en clair just stupid and
>> petty-minded.
>
>
> Now that's a political judgement.

I don't disagree. :)

Actually, I chose my words deliberately, so leaving open on purpose
whether the actual decision was based on political grounds or not.

But if one of the requirements R7RS-large has to fulfill is "no full
R6 compatibility" apparently for its own sake, I have a hard time
imagining non-political grounds.

If I am the only one who thinks that R7RS-large could or even should
be a vehicle to unite the Scheme worlds of R7RS-small and R6RS again,
asking the SC to revert their decision wouldn't be worth it.

If not, I would be happy if others spoke up as well.

>> The only practical solution that will also yield the best for the
>> community is in my opinion not to modify an existing implementation to
>> create an R7RS-large fork, but to persuade the maintainers of such an
>> existing high-quality implementation to steer their implementation
>> towards R7RS-large compatibility.
>
>
> If you want that to happen, you need to put the least burden on the implementers that is possible.

And one has to get the implementers on board.

>
>> vary a lot with respect to how companies influence them.
>>
>> >> In any
>> >> case, R7RS-large has to offer more than existing standards and (!)
>> >> tools.
>
>
> Small offers less than almost any Scheme implementation, but many implementors support it anyway.

R7RS-small was a step forward in the landscape of all
R5RS+-implementations, unifying things like the library system or
record systems.

R7RS-large has a different goal. Moreover, by its sheer size, much
fewer implementors could support it.