Consolidated response to a couple of points
Thanks for joining in!
I think the python 2 / 3 problem was cultural. This was mostly a
problem because companies think software should be written once and
never touched like physical buildings. Software should stand the test
of time over a period of hundred years. Except both the knowledge and
required skills is not there yet. The question of backward
compatibility should not be compared with CPython 2 /3 case only. Did
you read about the async yield from vs. async / await or even just the
async / await thing that I call "split brain syndrome"? no. It was and
is a pain. PR does not explain the whole story. There are many
approaches to bridge the gap between incompatible versions of the same
language (polyfill libraries such as python six, or even re-writing
the code such as 2to3.py or js babel). If Scheme aims to be the
perfect programming language, it should not be a primary concern
whether it is backward compatible or not.
I'm not familiar with Python past the 2-3 split.
I think a standard doesn't need to weigh in on design decisions like
that. If we standardize existing work, 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. This
is much less grueling for RnRS writers, and much more realistic.
What would be the advantage of moving to R8RS?
Putting the R6 vs R7 split behind us.
the idea of R6RS and R7RS-large is to write practical applications as well.
That is confusing. What is a practical application? That is mostly a
problem with R7RS WG1 and WG2 phrasing. What about educational
purpose? Steering software engineering toward a good direction? What
about different hardwares architecture or constraints? I think there
is a big difference (sadly) between being successful in the job market
(army of developers), or succesful commericaly (money making, which
scheme does), or educational material (ok) or even research material
(ok too). To summarize, except there is no visible army of developers
that practice Scheme on a daily basis, Scheme is successful.
IMHO RnRS is no longer a good primary vehicle for driving educational
values. After R5RS the language became so complex (out of necessity)
that no one can get all the details perfect. There will be ugly parts
for compatibility and other reasons, it's not really possible to avoid
anymore. R6RS is still very beautiful compared to most programming
languages, but many parts are far from the jewel that R5RS is.
Scheme's beauty should be presented in educational materials that
concentrate on the parts of the language that the author likes best, and
present a consistent vision that way.
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.
Chez / Guile / Racket have R6RS support, that does not say whether
R6RS is successful. Guix, the primary, biggest and almost only floss
program built with Guile, does not rely on R6RS. There are other big
programs / sets of programs such as C FFI automagic library or even
MES bootstrap that are used by Guix / Guile. All those are built with
Guile specific stuff e.g. the module system is not compliant, and even
if the rest was portable, it will require much tedious work to make it
run on another Scheme. Regarding Racket it is a big ecosystem but not
impact on the job market. Chez is the same, except there is little or
no reach in the floss community (the mailing list is silent, no big
floss project uses Chez). I think overall Gambit with JazzScheme,
Gerbil, and with secret industry users is more successful than those
you cited.
True. Some implementations have good traction on their own. But it makes
sense to study why portable Scheme doesn't get some of it. 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.
We can standardize the same stuff slower, with less rigor and more
give-and-take with Scheme implementors, until a solid spec emerges on
its own years later. If we start out pursuing a solid spec for threads
or FFI and won't rest before we are done, we'll be exhausted and unhappy.
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.
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.
Even if RnRS has broad compatibility, you can still aim for perfection
in your codebase, and if complex RnRS features are split into options,
there can be individual Scheme implementations that aim for perfection.
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.
