> If we standardize existing work

I am ok with that.

> then individual implementations
> can try different approaches to things like threads, and if a consensus
> emerges among them, then that consensus can be written up in RnRS.

Ok

> > What would be the advantage of moving to R8RS?
>
> Putting the R6 vs R7 split behind us.

I do not understand why R8RS output will solve that problem, that R7RS
can not. Except increment a number.

> IMHO RnRS is no longer a good primary vehicle for driving educational
> values.

I disagree.

Both R7RS and SRFI social processes and technical outputs are driving
educational values, whether it is initial education or improving or
increasing or perfecting existing knowledge. Compare that with Python
or even worse JavaScript: Python, mainly CPython community drive the
language, it is open to some extent but less welcoming than Rust (for
various reasons, among other things almost nobody is paid to do it),
JavaScript is on one side a complete fragmented chaos (that is where I
learned about the concept of "code pollution"), and good luck trying
to voice your concerns about ES spec, whether it is on github or on
W3C mailing list. More about W3C, I am still subscribed to two mailing
lists: wasm and RDF. WASM ML is completely silent, same with both
freenode and mozilla channels. RDF is an ivory tower of highly
educated PhDs [0].

Regarding "initial education", except maybe scratch visual programming
language, without picking a particular Scheme, R7RS is in a better
position than any other programming language that I know.

[0] https://github.com/w3c/EasierRDF/issues/79

> R6RS is still very beautiful compared to most programming
> languages, but many parts are far from the jewel that R5RS is.

I need to read a second time R5RS with a particular attention to that.

Speaking of R5RS, I was going to suggest R7RS-micro without the library system.

> > As far as portability goes, it is possible across R6RS and R7RS. Tho,
> > a test suite that is not normative, and easy to re-use will help a
> > lot.
>
> The details are inconvenient enough to cause problems with everyday
> work, and they are not on track to be fixed since RnRS has been and is
> caught up with pursuing its creators' vision.

I do not understand the last part of the sentence "and they are not..."

It is possible to write portable code. What is not possible is picking
a random program and running it on any Scheme.

> True. Some implementations have good traction on their own. But it makes
> sense to study why the portable Scheme doesn't get some of it.

The problem is not the standard but the lack of interest and the lack of users.

> It's clear we
> can't standardize things fast enough in RnRS to support all that work,
> and I think we should give up on the ambition to do that.

If R8RS gives up on portability, what will be the point of R8RS then?

Side notes, unrelated to the topic:

> If we start out pursuing a solid spec for threads

AFAIK, there is not much difference between the various threads API,
there is among several Scheme a denominator around POSIX thread
interface that has an SRFI. It seems to me there is no agreement on
whether threads are cooperative, or can be pre-empted, and whether
they run truly in parallel (different CPU cores) or not, and how to
communicate with the threads. Even if I was / am die-hard Chez user, I
do not know whether threads are necessary in the standard.

> or FFI and won't rest before we are done, we'll be exhausted and unhappy.

Again side note unrelated to the core of the topic: There is existing
work. It is possible to create DSL to interop with the host, and fine
tune the details, until it is good to be standardized. I am not
suggesting I will do the work, just that there is a way to make
progress on the subject.

>
> >> And adding new people to the community is hard if no-one can figure out
> > which of the warring RnRS, if any, is legitimate.
> >
> > Nobody cares (meme https://i.redd.it/b9ca0ux5wkq41.jpg). My
> > understanding there is three reasons to take part in SRFI / RnRS:
> >
> > - Improve / communicate / gather software engineering practices and
> > have a conversation with knowledgeable people
> >
> > - Grow your audience to attract users in to your implementation,
> > possibly aiming for Turing award or such
> >
> > - Have feedback on your own ideas
>
> RnRS is like the World Cup of design rigor. A team will be exhausted if
> every game they play all year round is a World Cup game.
> This is in fact what we are now seeing among RnRS contributors.

If it is an argument about scheme-live, then I agree. IMO scheme-live
does not call for R8RS.

>
> > None is Scheme specific. And forking the language and target JS or
> > wasm has a much bigger chance of success (including much more industry
> > adoption). What remains is "Scheme spirit" which I keep repeating is
> > according to me: aiming for perfection, and that leaves too much to
> > interpretation to guide any standardization work.

> If you pick a particular vision of perfection and drive it in RnRS, the
> next RnRS group will disagree and pick a different vision. It seems
> self-evident that the process is leading nowhere and is hurting Scheme's
> user community. If things keep going as they now do, there's no reason
> to believe that a future R8RS group will pick a vision compatible with
> the R6RS group or the R7RS-large group.
> They'll invent a third vision.

Then be it.

To keep it short, I think we agree on the scheme-live project, but we
disagree on how to proceed about the social and technical aspect of
scheme-live project. If I reply to future messages, I will do it
privately and I recommend you do the same.