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 07:28 UTC

Am Fr., 25. Feb. 2022 um 00:53 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Sun, Feb 20, 2022 at 10:05 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> In fact, if R7RS-large wants to fulfill the goals that are set for it,
>> it will have to include a subset equivalent of R6RS anyway. Now with
>> syntax-case having become a part of R7RS-large, everything speaks for
>> actually using R6RS as this subset and not to create something
>> incompatible.
>
>
> When the Steering Committee (Clinger, Feeley, Hanson, Rees, Shivers) appointed me chair of WG2, they asked me to draft the charter.  My original included a clause requiring compatibility with R6RS.  I got more pushback from the SC on that clause than on the whole rest of the charter.  The SC definitely did *not* want full R6 compatibility, although they were okay with transplanting components of it, as the current charter provides for. I am the SC's servant, so if you want change here, you need a political solution: you can lobby the SC to change its mind, or raise a groundswell of public opinion that the current SC should be replaced.

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 is en clair just stupid and
petty-minded.

>> Thus, we will probably
>> have to build on existing implementations; no one can recreate what
>> went into Gambit, Chez, Racket, etc. for twenty or thirty years or
>> more in a year or two.
>
>
> I agree with this.  Indeed, we may need two: one based on an existing R6 and another based on an existing Small.  The issue then is which implementations require the least modification and/or are easiest to modify.

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.

>> At least as much as with implementations, we should be concerned with
>> the audience of the standard. It's a difference if we want to address
>> some niche programming projections or if we want to see wider adoption
>> of the resulting language in mainstream software development.
>
>
> I don't think we can see *wide* adoption in 2022 or later without support from a commercial company, in which case the language will be what the company wants and not the community.

I agree with the danger that lurks here. On the positive side, we see
that a lot of programming languages with a wide adoption exist that
vary a lot with respect to how companies influence them.

>> In any
>> case, R7RS-large has to offer more than existing standards and (!)
>> tools. At the moment, for example, using R6RS together with some
>> existing portable libraries (e.g. SRFIs) still gives me a more
>> productive environment than the current R7RS-large.
>
>
> Please tell me which libraries you have in mind.

I mean that adding more and more portable libraries does not really
create an argument in favor of R7RS-large because these libraries
(which exist as SRFIs with implementations in the public domain) can
simply be used with an R6RS system. The only difference is that
R7RS-large allows me to write, say, (import (scheme list)), where for
an R6RS system, I would write (import (srfi : 1)).

R7RS-large would get a unique selling point once its core would
surpass that of R6RS, but this is still far from being true even after
so many years of development. Apparently, the SC didn't want it but
the R7RS-large project would be much more successful (and possibly
even finished) had R6RS been taken as its base so that one could have
directly started to build its roof (and necessary bits for R7RS-small
compatibility). At the moment, we are still building the roof with the
foundations still in flux and with no clear direction.