> 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.
SRFI 18 actually does that. It is over-complex and I would like to have a SRFI providing a smaller subset, supplemented by a gochan or CML built on top.
RDF is an ivory tower of highly
educated PhDs [0].
Well, and me. I have no degrees, and call myself an ontological engineer rather than an ontologist.
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.
Remember that MIT ditched Scheme in favor of Python precisely because professional programming today is mostly gluing things together. A friend of mine once said that programming in Scheme is like building a ship in a bottle: you have to do everything from scratch except making the tiny little parts.
> R6RS is still very beautiful compared to most programming
> languages, but many parts are far from the jewel that R5RS is.
I agree that the language is and continues to be a jewel, but the libraries are not. Why map but not vector-map, for example? No reason except tradition. R7RS fixed that.
Speaking of R5RS, I was going to suggest R7RS-micro without the library system.
Well, it is conformant to provide only (scheme base), which makes all the library support unnecessary. Someone should write a demo version of R7RS-small like that.
If R8RS gives up on portability, what will be the point of R8RS then?
See Clinger's paper "R7RS Considered Unifier of Previous Standards". His view (which I did not foresee but with which I agree) is that R6RS focused on portability, R7RS-small on interoperability.
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.
If they are used for concurrency rather than parallelism, I think none of these things matter. Parallelism needs a separate API; I have a pre-SRFI based on "eager promises" that execute right away but may be suspended by the implementation whenever anything "too hard" is attempted. This is based on Racket.
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.
The problem is in how you do the glue: in weird-looking Scheme that provides what C expects, or in weird-looking C that provides what the Scheme implementation expects. That's a distinction I see no way to bridge. We also need a standard groveler like the one for CL's CFFI.