The reaction to John Cowan’s resignation as chair of the R7RS Large working group has been somewhat wider than I think anyone expected, making it onto general interest programming forums. Scheme may be a small island, but when it has an earthquake, it makes waves through the whole archipelago of programming languages. For the most part, these waves caused only confusion about what all this means.
What’s happening? Is Scheme dying? Will R7RS carry on? Find out below!
Note for the sake of disclosure of interests: I’ve explicitly invited the steering committee to consider me a candidate to replace John Cowan. This is also purely my own view on what has happened, not anyone else’s.
In the beginning, Scheme was created. This made a lot of people very happy and has widely been regarded as an excellent idea.
Scheme progressed from a master’s research project through to standardized language through interest in using it in introductory computer science education (think Structure and Interpretation of Computer Programs), programming language research, and as a minimal dialect of Lisp for environments with limited resources. An informal group evolved the language through revisions known as RnRS (a mathematical pun with a reference to Algol hidden in it), up to R5RS in 1998, which was the first programming language to standardize a hygienic macro system.* †
To further evolve the language, a process called SRFI was set up, which basically provided the equivalent of Python PEPs or whathaveyou. Some SRFIs, like SRFI 1 (a comprehensive library of list utility procedures) were wildly popular and many implementations took them up; others found no adoption at all. So it goes.
To move beyond R5RS, a Steering Committee was formed in 2004 which appointed editors to specify an R6RS. When they were done in 2006, the reaction from the Scheme community was … mixed. Compared to any previous new RnRS, the R6RS represented the biggest development from its the preceding Rn−1RS yet. Some people loved it and still love it. For others, it seemed to be the worst thing to ever happen to Scheme. Generally, their criticisms boiled down to: it’s too big for certain use cases; there are too many things implementations are required or forbidden to do, limiting implementations’ ability to create their own extensions to the language; some changes from existing Scheme practice seem gratuitous (for example, instead of adopting SRFI 1, or even a subset of it, R6RS created its own library with much of the same functionality under incompatible names); it messes up the ‘spirit of Scheme’ (as understood by those who criticized the report). Some implementations added support for it; others refused to touch it with a barge pole.‡ Even some implementations which supported it wilfully ignored its strictest requirements.
A new Steering Committee was elected by those interested in Scheme in 2009, which recognized that Scheme was trying to serve two purposes which couldn’t be accommodated in one report. Those who liked R5RS liked it because it was small and flexible; those who liked R6RS wanted something bigger and more practical for writing real, production programs on modern computers. Thus, they planned to revise the language again and split it into two parts: small and large. New working groups were appointed, and the first one delivered the report on the R7RS small language(PDF) in 2013. This was mostly well-received by those who appreciated the simpler nature of R5RS, and pretty much every actively maintained implementation which had rejected R6RS adopted R7RS small.
Getting the large language done has been a much slower process, in part because of its increased scope. In contrast to R6RS (which used the SRFI process to gather feedback on some, but not all of its new features), R7RS Large was going to be almost entirely SRFI-based. This meant adopting popular existing SRFIs, but also writing a whole lot of new ones. Anyone in the Scheme community was invited to vote on which ones made it into the language. To attempt to speed things up, in 2022 an issue tracker was established (until then, to-do items had been in a document maintained by the chair, John Cowan). At the same time, the community identified that there were two groups with slightly different concerns about what R7RS Large would look like: some were concerned that the small language itself didn’t impose strict enough semantics for a safe high-level programming language,§ and wanted other cool new features like delimited continuations; others wanted a language with a large standard library like Python’s. For the most part, those in the former group were concerned that most progress so far had been on the standard libraries, and there was an emphasis on compatibility with the small language which seemed to undermine the idea of new core language features. So the report was split into ‘Foundations’, with stronger error checking than the small language and other new features including an advanced macro system, and ‘Batteries’, which would give us the big standard library others wanted. In theory two groups would be formed, each working on their part.
In practice, the working group for R7RS Large has consisted of two groups split along very different lines:
Since these changes in 2022, the small group actively working on the language has overwhelmingly focussed on the Foundations. Those who expressed that their main interest was in the Batteries have got themselves involved in Foundations work, and (to the extent Batteries work has continued) vice versa.
Debates on the Foundations have got bogged down a lot in questions of R6RS compatibility, even though the Foundations report at the outset was going to ensure, at least, that nothing would prevent an R6RS implementation from also supporting R7RS. The details of this have proven the most controversial points: should we base all our new Foundations features on R6RS? Should R6RS in its entirety become part of the Foundations, even though some of R6RS is clearly Batteries stuff, like that list library I mentioned earlier? Should R7RS implementations be required to support R6RS as well? Some of these arguments have undermined the settlement reached in 2022, because Batteries people don’t want the Foundations people to work on (what they perceive to be) the assumption that the Batteries will never be done. On the other side, it’s argued that simply incorporating everything from R6RS — possibly in revised form — would settle a lot of questions about the Foundations without having to debate them.
There are also procedural disagreements: Marc Nieper-Wißkirchen, who was in theory responsible for the Foundations, is not a fan of putting things to a vote of the larger community, because he feels a report created by democratic vote won’t necessarily be a coherent whole in the end. He wants to work by unanimous consensus, i.e. ‘as long as nobody objects to something, it goes in’. Unanimous consensus of the editors was actually how reports up to and including R5RS were written (explaining the smaller size of those reports), but this stance does rule out one option for resolving these fundamental disagreements where unanimity is not possible.
According to the charter for the working group for the large language, the Steering Committee now has to make a decision: either they appoint a new chair who they think can fix things; or they dissolve the working group and give up on the R7RS Large language.
The number of people who could credibly become the new chair is limited; the number of people who want it even fewer. When John Cowan informed me he intended to resign (the weekend before he announced it publically), I immediately suggested a successor, whom John thought was a good choice to recommend to the Steering Committee. But, when asked, that person just as immediately turned it down. Thus John was not able to recommend any course of action in his resignation letter. The credible choices of a new chair are, in my view: someone from within that smaller active working group (one of whom, as mentioned, already said they don’t want to be chair); or someone from the Steering Committee itself. There are a few possible candidates in the wider Scheme community, but they seem even more unlikely to want to take on the task: it would be cool to have Guy Steele as chair, but I think he’s still busy with Java or something. So far I appear to be the only person mad enough to actually want to try to take on the responsibility of fixing things (though it’s possible someone else asked the Steering Committee privately to consider them a candidate, too).
Equally, though, dissolving the working group seems premature. Everyone who is working on the language is still excited about it and wants to see it completed: work on proposals and specs has continued even while we are without a chair to present them to the voting community. It seems wrong to cancel the project in these circumstances, even if any future chair’s efforts to resolve the conflicts might be seen as ‘last ditch attempts’ before actually, finally giving up.
Somewhat concerningly, there’s also a third possibility. (Update: This possibility now seems off the table, see below.) All of the members of the Steering Committee have become somewhat less active in the Scheme community in recent years. Though we’ve seen occasional input from individual members, the Steering Committee as a body hasn’t taken any action since 2013 when the small language report was ratified. When the changes made in 2022 were being discussed, we got no guidance from the Committee at all. In short, we’re not sure the Steering Committee exists as a single, functioning entity any more.
So it’s possible that the Steering Committee does nothing, which would amount to de facto ending the process, but in the least satisfying possible way. The working group would still technically exist, but without a chair. This might be the end of Scheme standardization altogether, though I hope we could at least find some source of authority to give some kind of future specification its seal of approval.‖
What I wrote in my statement requesting the Steering Committee consider me a candidate for new chair is true: Scheme has an outsized importance in the world of programming languages compared to its actual use in industry, because it has so often pioneered features that later broke into the mainstream. Proper tail calls as the fundamental means of iteration is now standard in functional programming. Transformation to continuation-passing style as the basis of compilation likewise. Hygienic macros — now part of Rust and even being considered in Python — were pioneered by researchers who used Scheme as their test bed. That research became part of the Scheme standard in R5RS and R6RS. In functional programming, a lot of research is being done at the moment in algebraic effects, which might revolutionize how side-effects like I/O are done in languages like Haskell — and all this work is based on research into delimited control operators, research which was done by Schemers. That’s research we want to put into the standard in R7RS Large. Above all, Scheme continues to be the first language of reference for all those who believe, in the words of the introduction to the reports, that ‘programming languages should be designed not by piling feature on top of feature, but by removing the restrictions and limitations that make additional features seem necessary’.
It would be a damned shame if this were the end of the road for standard Scheme, but it doesn’t have to be so. I have my plan to save it, but let’s wait and see what the Steering Committee has to say.
Daphne Preston-Kendal, 18 August 2023The Steering Committee has formally acknowledged and accepted John Cowan’s resignation. Thus, the possibility of the working group being left in permanent chairless limbo no longer seems to exist.
* Unfortunately, the standard hygienic macro system in R5RS was quite underpowered because it represented a minimum consensus about how macros should work. So the entire concept of hygienic macros in general was pooh-poohed by a lot of Common Lispers mostly due to a misconception that that was all that hygienic macros could do, creating a rift in the Lisp community – even though all Scheme implementations in practice provide a lower-level, more powerful macro system in which you can do everything you can do with unhygienic macros and more. ↑
† Nearly twenty years later, hygienic macros – and program-structural macros in general – first made their way into a mainstream programming language when Rust took off. Hooray! ↑
‡ A synopsis of all the specific reasons people voted against accepting the R6RS report, together with responses from John Cowan as contributor to R7RS, can be found on the wiki page SixRejection. Note that the responses are not any official statement of any working group, and in some cases have become obsolete because the decisions they reference have been superseded. ↑
§ Indeed, the small language doesn’t even enforce bounds checking, even though almost all implementations do it. Such are the sacrifices for a language which might be expected to work on a tiny microcontroller. ↑
‖ The situation reminds me somewhat of the First Council of the Vatican, which was suspended in 1870 after the unifiers of Italy invaded Rome, but was still technically in session until it was formally closed in 1960 in preparation for a new, Second Council of the Vatican (the one your traditionalist Catholic aunt complains about all the time). Who will formally dissolve the R7RS working group eighty years from now to produce R8RS? ↑